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NOTES 

1. In this Recommendation, the expression "Administration" is used for conciseness to indicate both a 
telecommunication administration and a recognized operating agency. 

2. The status of annexes and appendices attached to the Series V Recommendations should be interpreted as 
follows: 

an annex to a Recommendation forms an integral part of the Recommendation; 

an appendix to a Recommendation does not form part of the Recommendation and only provides some 
complementary explanation or information specific to that Recommendation. 
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Recommendation V.42 



ERROR-CORRECTING PROCEDURES FOR DCEs 
USING ASYNCHRONOUS-TO-SYNCHRONOUS CONVERSION 



(Melbourne, 1988; revised at Helsinki, 1993, and at Geneva, 1996) 



The ITU-T, 



considering 



(a) 



that the use of high-speed DCEs for transmission of asynchronous data on the GSTN is increasing; 



(b) 

protocol; 



that there is a demand for an improved error performance on such connections by the use of an error-correcting 



(c) 



that there is a need to interwork with DCEs not providing such a protocol, 



declares 



that the error-correcting procedures to be followed by DCEs using asynchronous-to-synchronous conversion are as 
specified in this Recommendation. 



1.1 General 

This Recommendation describes error-correcting protocols for use with V-Series duplex DCEs to accept start-stop data 
from the DTE and transmit in synchronous mode. Use in half-duplex DCEs is for further study. 

This Recommendation contains an HDLC-based protocol referred to as the Link Access Procedure for Modems 
(LAPM). Additionally, an alternative procedure is defined in Annex A. 

NOTE I - There are DCEs currently in operation that implement the protocol defined in Annex A. 

Compliance with this Recommendation requires implementation of both protocols. However, unless otherwise specified 
by user options, two V.42 DCEs will communicate using LAPM. A V.42 DCE dialling or dialled by DCEs currently in 
operation that only use the protocol in Annex A will communicate using that protocol. 

It is the intention of the ITU-T to further enhance and extend the LAPM protocol. Several topics for further study are 
listed in Appendix V. It is not intended to further enhance the protocol defined in Annex A. 

The principal characteristics of the protocols are as follows: 

a) interworking in the non-error-correcting mode with V-Series DCEs that include asynchronous-to- 
synchronous conversion according to Recommendation V.14; 

b) error detection through the use of a cyclic redundancy check; 

c) error correction through the use of automatic retransmission of data; 

d) synchronous transmission through the conversion of start-stop data; 

e) an initial handshake in start-stop format which minimizes disruption to the DTEs. 

NOTE 2 - Technical changes have been introduced since the 1988 version of this Recommendation, and make refinements 
to the operation of the LAPM protocol. The following clause and subclauses were affected: 7.2.1.3, 7.3, 7.4, 7.5, 7.9, 8.3, 8.4, 8.5, 
8.13, 9.3, 10, 12.2.2, 12.3, A.7.2,1. Implementations conforming to the 1988 version remain fully compatible and conformant with 
this version. 
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1.2 Relationship to other international standards 



The error-correcting protocol defined in the main body of this Recommendation can be specified in terms of the 
High-level Data Link Control (HDLC) formats and procedures. In particular, it makes use of the balanced asynchronous 
class (BAC) of HDLC procedures. The basic mode (i.e. without options) of this protocol makes use of HDLC "optional 
functions" 1, 2, 4, 6, 8 and 10. (This mode is identical to Recommendations Q.920/Q.921.) When using optional 
procedures of this error-correcting protocol, HDLC "optional functions" 3 (for selective retransmission), 12 (for loop- 
back test), and 14 (for 32-bit FCS) are added. 



2 Definitions 

An error-correcting protocol may be used with a signal converter to create an error-correcting DCE. 

2.1 Data circuit-terminating equipment (DCE): In this Recommendation, a DCE, when used without further 
qualification, consists primarily of three sections: interchange circuits for the interface to the DTE and signal converters 
for transmission over telephone circuits. A control function is used to provide a user interface to coordinate the operation 
of the interchange circuits and the signal converter. The structure of a DCE is shown in Figure 1 . 

a) The DTE exchanges data with the DCE through a V.24 interface. The data is exchanged in start-stop 
format. 

b) The signal converter provides the modulation and demodulation of signals exchanged on the GSTN, or 
two-wire point-to-point leased circuits. 

c) The control function provides overall control and coordination between each of the DCE components. 
Further, the controller provides the specific operational configuration for the DCE selected by the user. The 
user interface to the controller is implementation dependent. 



DTE < ► 
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Control 
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converter 
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T1 40031 0-93/d01 



FIGURE 1/V.42 
DCE 



2.2 error-correcting DCE: The logical structure of an error-correcting DCE is shown in Figure 2. The error 
control functions implement the error-correcting protocols of this Recommendation. 
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FIGURE 2/V.42 
Error-correcting DCE 
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3 Abbreviations 

For the purposes of this Recommendation, the following abbreviations are used: 



ADP Answerer Detection Pattern 

C/R Command/Response bit 

CRC Cyclic Redundancy Check 

DCE Data Circuit-terminating Equipment 

DISC Disconnect (frame) 

DLCI Data Link Connection Identifier 

DM Disconnected Mode (frame) 

DTE Data Terminal Equipment 

FCS Frame Check Sequence 

FI Format Identifier 

FR M R Frame reject (frame) 

GI Group Identifier 

GL Group Length 

GSTN General Switched Telephone Network 

HDLC High-level Data Link Control (protocol) 

1 Information (frame) 

LA Link Acknowledgement (frame of the alternative error-correcting procedure) 

LAPM Link Access Procedure for Modems 

LD Link Disconnect (frame of the alternative error-correcting procedure) 

LN Link attention (frame of the alternative error-correcting procedure) 

LNA Link attention acknowledgement (frame of the alternative error-correcting procedure) 

LR Link Request (frame of the alternative error-correcting procedure) 

LT Link Transfer (frame of the alternative error-correcting procedure) 

ODP Originator Detection Pattern 

P/F Poll/Final (bit) 

PI Parameter Identifier 

PL Parameter Length 

PV Parameter Value 

REJ Reject (frame) 

RNR Receive not Ready (frame) 

RR Receive Ready (frame) 

SABME Set Asynchronous Balanced Mode Extended (frame) 

SREJ Selective reject (frame) 

s-SREJ Single-Selective Reject (procedure) 

m-SREJ Multi-Selective Reject (procedure) 

UA Unnumbered acknowledgement (frame) 

XID Exchange identification (frame) 
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Establishing an error-corrected connection 



A connection over which the DCE's error-correcting protocol operates is established in two phases. Initially, a physical 
connection is established between the peer signal converters, as specified by the appropriate V-Series Recommendations. 
After the physical connection has been established, the signal converter is in the data mode. 

Error-correcting DCEs shall provide a mechanism for enabling or disabling establishment of the error-correcting 
protocol. This mechanism may be used in situations where the attempt to establish the error-correcting protocol 
interferes with operation of the remote DTE or when error-correction between DCEs is not desired or needed (such as 
when the DTEs provide higher-layer error control). The ability to initiate or terminate the error-correction protocol 
independent of the physical connection (i.e. while a physical connection is already in progress or retained) may 
optionally be provided, but coordination of protocol initiation at times other than immediately following establishment 
of the physical connection is not a subject of this Recommendation. 

If establishment of the error-correcting protocol is enabled, then after the signal converter is in the data mode, the peer 
error control functions will establish the error-corrected connection. 



5 Interchange circuits affected by error correction 

The affected circuits are listed in Table 1 . 

The interconnection of the functional elements of an error-correcting DCE is shown in Figure 3. 



6 Overview of error-correcting DCE operation 
6.1 General 

An error-correcting DCE, as depicted in Figure 2, contains four components: 

a) V.24 interchange circuits; 

b) a signal converter; 

c) a control function; 

d) an error control function. 

While the first three components are also found in the DCE depicted in Figure 1, the control function in an error- 
correcting DCE is enhanced beyond the functionality of a control function in a DCE. For example, the control function 
in an error-correcting DCE shall be capable of determining whether the remote DCE is an error-correcting DCE or a 
non-error-correcting DCE. The error control function is unique to an error-correcting DCE. 

Clause 7 provides a detailed description of the control function. Clause 8 and Annex A provide detailed descriptions of 
the error-correcting protocols and their interactions with the control function. 

NOTE - The decomposition of the functionality of an error-correcting DCE into a control function and an error control 
function, as well as the description of their interaction, is not meant to imply a particular method of implementation. 

The remainder of this clause gives an overview of the control function and the error control function. 

TABLE 1/V.42 



Interchange circuits affected by error control 



No. 


Description 


103 


Transmitted data 


104 


Received data 


106 


Ready for sending 


109 


Data channel received line signal detector 


133 


Ready for receiving 
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a) See clause 8 and Annex A. 

b) See clause 7. 



FIGURE 3/V.42 
Circuits affected by error control 



6.2 Overview of the control function 

The control function shall be responsible for the overall coordination of functions within a DCE. When realized in an 
error-correcting DCE, the control function shall be responsible for the following additional aspects of operation: 

a) conducting an initial handshake to determine whether the remote DCE is also a V.42 error-correcting 
DCE; 

b) falling back to a non-error-correcting mode to interwork with V-Series DCEs that include asynchronous- 
to-synchronous conversion according to Recommendation V.14; 

c) coordinating the negotiation and/or indication of any necessary parameters; 

d) coordinating the negotiation of optional procedures; 

e) coordinating the establishment of an error-corrected connection after the establishment of the physical 
connection with a peer error-correcting DCE; 

0 coordinating the delivery of data between the V.24 interface and the error control function so that data 
loss, to the extent possible, does not occur due to congestion on the DTE/DCE or DCE/DCE interface 
(this includes inspection of the characters received from the V.24 interface to determine whether the DTE 
has invoked flow control); 

g) converting data received on the V.24 interface with start-stop framing to a format suitable for 
synchronous transmission; 

h) converting data received on the DCE/DCE interface in synchronous format for delivery with start-stop 
framing on the V.24 interface; 

i) processing a break (spacing) signal received on the V.24 interface for synchronous transmission; 
j) processing a break indication received on the DCE/DCE interface; 

k) coordinating a loop-back test; 

l) re-negotiating parameters if conditions warrant it; and 

m) releasing the error-corrected connection in an orderly fashion. 
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6.3 Overview of the error control function 

The error control function shall be responsible for the operation of the protocol that realizes the error-corrected 
connection. The protocol shall have the following functional capabilities: 

a) negotiation and/or indication of appropriate operational parameters; 

b) negotiation of optional procedures; 

c) establishment of an error-corrected connection; 

d) transmission and reception of data; 

e) error detection and correction; 

0 transmission and reception of a break signal; 

g) initiation of and responding to loop-back testing; and 

h) orderly release of an error-corrected connection. 

6.4 Communication between the control function and the error control function 

Communication between the control function and error control function is modelled as a set of abstract primitives, which 
represents the logical exchange of information and control to accomplish a task or service. In the context of this 
Recommendation, the control function is viewed as the "service- user" while the error control function is viewed as the 
"service-provider". 

A primitive is of the general form: 

X-NAME type 

where: 

X designates a particular pair of communicating entities; 

NAME designates the service being invoked; 
Type designates the initiator of the communication. 
Table 2 shows the services expected by the control function (i.e. the values that "NAME" can take on). 

There are four "types" of primitives. These are: 

a) a request primitive, which is used by the service-user to request a service; 

b) an indication primitive, which is used by the service-provider to notify the service-user of a request for a 
service or an action initiated by the service-provider; 

c) a response primitive, which is used by the service-user to respond to a request for a service; and 

d) a confirmation primitive, which is used to indicate that a service request has been completed. 

TABLE 2/V.42 



Services expected by the control function 



Service 


Primitive 


Clause 


Establish an error-corrected connection between peer error-correcting 
entities 


L- ESTABLISH 


7.2.2 


Transfer data 


L-DATA 


7.3 


Release an error-corrected connection 


L-RELEASE 


7.2.2, 7.7 


Transfer a break signal 


L-SIGNAL 


7.4, 7.5 


Negotiate/indicate parameter values and optional procedures 


L-SETPARM 




Conduct a loop-back test between error-correcting entities 


L-TEST 


7.8 
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7 Operation of the control function 

Subclause 6.2 provided an overview of the control function. This clause details the operation of the control function, 
which completely controls all phases of error control function operation. 

7.1 Physical handshake 

The procedures for establishing a physical connection are specified by the appropriate V-Series Recommendations. After 
the physical connection has been established, the control function shall be aware of the following information: 

a) whether the DCE is the originating or answering DCE; 

b) various aspects concerning the transmission facility (e.g. speed); and 

c) the character format used by the DTE. 

The method for determining the above information is beyond the scope of this Recommendation. This information is 
used to govern some aspects of error-correcting-DCE operation. 

7.2 Phases of error-correcting protocol establishment 

Upon receipt of an indication that the signal converter element has completed carrier handshake and that the physical 
connection is ready for communications, the control function initiates error-correcting protocol operation. This process 
has been divided into two phases: 

a) the detection phase determines whether the remote DCE is also an error-correcting DCE; and 

b) the protocol establishment phase determines parameter values and optional procedures to be used, as 
necessary, and establishes the error-corrected connection. 

The detection phase has been designed to avoid the potential disruption to the called DTE that could occur if the control 
function immediately entered the protocol establishment phase and the remote DCE was not an error-correcting DCE. 
However, the detection phase may optionally be disabled by the user if, for example, the answering DCE is known to be 
of a compatible type. The error-correcting DCE does not transmit any data received on the V.24 interface to the 
remote DCE in error-correcting mode until the successful establishment of the error-corrected connection. At that time, 
the control function adjusts the V.24 interface to inform the DTE that DTE-to-DTE data transfer may commence. 

7.2.1 Detection phase 

This phase allows the control function to verify the presence of a remote error-correcting DCE. 

Considerations for interworking between an error-correcting DCE and a non-error-correcting DCE are given in 
Appendix I. 

7.2.1.1 Determination of role 

The success of the detection phase depends on both control functions knowing their roles as originating DCE 
(hereinafter called the originator) or answering DCE (answerer). The role is determined by the frequencies used for 
communication or the role assumed during carrier handshake as assigned in the particular modulation Recommen- 
dations. In the situation where no phone call is placed (such as in a "leased line" connection) or where, because of the 
nature of the modulation, there is no clear differentiation between originator and answerer, the roles must be determined 
by parameterization (stapping options or other user indication of desired role to the control function). 

7.2.1.2 Originator actions 

The detection phase actions by the originator may be disabled by the user. In this case, the originator moves directly to 
the protocol establishment phase (see 7.2.2). 

If the detection phase is enabled, when circuits RFS and RSD go ON, indicating a successful connection between the 
signal converters, the originator shall then send the Originator Detection Pattern (ODP). The ODP is defined as the 
following pattern of bits (listed left to right in order of transmission): 

0 1000 1000 1 11... 11 0 1000 1001 1 11... 11 
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This pattern represents DC1 with even parity, followed by 8 to 16 ones, followed by DC1 with odd parity, followed by 
8 to 16 ones. The ODP is transmitted for the period of the detection phase timer, T400 (see 9.1.1) or until the Answerer 
Detection Pattern (ADP), which is defined in 7.2.1.3, is received. 

All transmissions are sent using the scrambling function of the signal converter (if any) and in synchronization with the 
derived carrier clock signal (i.e. without use of any inherent asynchronous speed- matching capability of the signal 
converter that would otherwise be used in an asynchronous non-error-correcting DCE). 

The originator shall examine the incoming bit stream from the receiver signal element for the presence of the ADP. 
Correct receipt of the characters from at least two adjacent ADPs shall be required for the originator to determine that 
the pattern is being observed. 

If the ADP is not observed within the period of T400 (see 9.1.1), following completion of the transmission of the last 
repetition of the ODP the originator shall decide that the answerer does not possess V.42 error-correcting capability. In 
this case, the originator may fall back to non-error-correcting mode or may attempt to detect the presence of an 
alternative error-correcting capability, such as that described in Annex A. 

If the ADP is observed within the period of T400, the originator stops transmission of the ODP and takes the appropriate 
action based upon the ADP received (e.g. if "EC" is received, initiate LAPM). 

7.2.1.3 Answerer actions 

Upon indication of successful establishment of a connection between the signal converters, the control function of the 
answerer shall transmit I -bits (mark) until termination of the detection phase, receipt of the ODP, or detection of the start 
of the protocol phase (the start of the protocol phase is indicated by receipt of continuous flags, or of an LAPM or 
alternative procedure protocol frame). 

The answerer shall examine the incoming bit stream from the signal converter for the presence of the ODP, which is 
defined in 7.2.1.2. Correct receipt of at least four DC Is of alternating parity shall be required for the answerer to 
determine that the ODP is being observed. 

If, after establishment of the physical connection, the ODP is not observed within the period of T400 (see 9.1.1) and the 
start of the protocol establishment phase is not observed within the same period, then the answerer shall decide that the 
originator is not capable of V.42 error-correcting operation and shall fall back to non-error-correcting operation. 

If the ODP is observed, the answerer interprets this as an indication from the originator that the originator is capable of 
error-correcting operation and desires to continue into the protocol establishment phase. The answerer shall immediately 
send one of the Answerer Detection Patterns (ADPs) defined in Table 3 at least ten times. 

All transmissions are sent using the scrambling function of the signal converter and in synchronization with the derived 
carrier clock signal. 



TABLE 3/V.42 



Answerer detection patterns 



Type 


Meaning 


0 1010 00101 11. ..11 01100 00101 11. ..11 ' 
(E) and (C) separated by 8 to 16 one's 


V.42 supported 


0 1010 00101 11. ..11 0 0000 00001 11.. .11 
(E) and (Null) separated by 8 to 1 6 one's 


No error-correcting protocol desired 


0 1010 00101 11.. .11 0 0000XXXX1 11. ..11 


The remaining 15 -code points are reserved for 
future study and assignment 


NOTE - The above bit patterns are listed left to right in order of transmission (i.e. low-order bit 
transmitted first). 
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7.2.2 Protocol establishment phase 

The protocol establishment phase is initiated by the originating DCE upon successful completion of the detection phase 
if enabled. The purpose of this phase is to: 

a) negotiate and/or indicate the parameters and any optional procedures that govern the subsequent operation 
of the DCE; and 

b) establish the error-corrected connection. 

Negotiation/indication may be omitted if default parameter values and procedures are satisfactory. When needed, the 
control function shall follow the procedures in 7.6 for the negotiation/indication of parameter values and optional 
procedures. 

After the negotiation/indication process has been completed, the originating DCE initiates establishment of the error- 
corrected connection. The control function in the originating DCE instructs its error control function to initiate 
connection establishment by issuing an L-ESTABLISH request primitive. 

Upon receiving an L-ESTABLISH indication primitive from its error control function, a control function must determine 
whether it wishes to accept the request for error-corrected connection establishment. If it wishes to accept the request, it 
issues an L- ESTABLISH response primitive; data may now be transmitted over the error-corrected connection. 
Otherwise, the control function issues an L-RELEASE request primitive to the error control function. The control 
function may fall back to operation in a non-error-control mode or it may release the physical connection. 

After having issued an L-ESTABLISH request primitive, the control function, upon receipt of an L-ESTABLISH 
confirmation primitive, considers the establishment of the error-corrected connection to be completed and may transmit 
data over it. If the control function receives an L-RELEASE indication primitive (e.g. as a result of a failure to set up the 
error-corrected connection or the remote control function refusing to accept error-corrected connection setup), then it 
may fall back to operation in a non-error-correcting mode or it may release the physical connection. 

7.3 Data transfer 

Upon completion of the protocol establishment phase, the control function shall request transmission by the error control 
function of data received on the V.24 interface. Regardless of the character format used, each character received on the 
V.24 interface shall be transmitted as an 8-bit character (without start and stop bits) across the DCE/DCE interface. 

Annex B provides the mapping of various character formats to an 8-bit character format. 

NOTE - It is beyond the scope of this Recommendation to specify how the control function determines when to request the 
error control function to transmit data. Some considerations are given in Appendix II. 

To transmit data, the control function shall issue an L-DATA request primitive to the error control function. This 
primitive shall indicate the data to be transmitted. 

Upon receipt of an L-DATA indication primitive, the control function shall deliver the received data to the 
V.24 interface. Each character shall contain the proper start-stop framing. 

7.3.1 Flow control across the DTE/DCE interface 

The control function will be capable of indicating to the DTE a temporary inability to accept data on circuit 103 (DCE 
not-ready condition), and of recognizing a corresponding indication from the DTE (DTE not-ready condition). Upon 
receiving such an indication, the DCE shall and the DTE should complete transmission of any partially-transmitted 
character and then cease transmitting data on circuit 104 (103) and clamp circuit 104 (103) to binary 1. When the not- 
ready condition is cleared, the DCE (DTE) may resume the transmission of data on circuit 104 (103). 

The flow control indication may be performed in one of two ways: 

a) using circuits 133 and 106: 

a DCE not-ready condition may be indicated by turning circuit 106 OFF and cleared by turning 
circuit 106 ON; 

a DTE not-ready condition may be recognized by an ON-to-OFF transition and cleared by an OFF-to-ON 
transition of circuit 133; 
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b) using DC 1 /DC3 characters (XON/XOFF functions): 

a DCE not-ready condition may be indicated by transmitting a DC3 character and cleared by transmitting 
a DC1 character on circuit 104; 

a DTE not-ready condition may be recognized by the reception of a DC3 character and the condition 
cleared by the reception of a DC1 character on circuit 103. 

Optionally, DC1 and DC3 characters received from the DTE may remain in the data stream. 

Both techniques a) and b) shall be provided; however, the choice of technique is a user-configurable option. 

The response times to the DCE of indication of a DTE not-ready condition and of the DTE to indication of a DCE not- 
ready condition are for further study. These times should be kept as short as practical. DCEs should accommodate 
latency in DTE recognition of the DCE not-ready indication by accepting several characters on circuit 103 after the 
indication is given. 

If a break signal is the next item to be delivered across the DCE/DTE interface, it shall be delivered regardless of the 
flow control state. In the case of a non -expedited/non-destructive break, data to be delivered prior to the break remains 
subject to flow control. 

7.4 Transfer of break signal 

Upon receipt of a break signal on the V.24 interface, the control function shall determine: 

a) how to handle data (discard or deliver) not yet transmitted across the V.24 interface or to the remote 
DCE; and 

b) in what sequence (in sequence or preceding) the break signal shall be delivered to the remote 
V.24 interface with respect to data delivery. 

The control function shall issue an L-SIGNAL request primitive to the error control function, indicating the break- 
handling option corresponding to the appropriate actions. The break-handling option and the actions to be followed are 
given in Table 4. The L-SIGNAL request primitive may also indicate the length of the break. If break lengths are not so 
indicated, the L-SIGNAL request primitive shall be issued at the earliest opportunity following detection of the break 
condition on the DTE/DCE interface. If break lengths are being indicated, the L-SIGNAL request primitive shall be 
issued at the earliest opportunity following the detection of the end of the break condition. Should the break condition 
continue for more than 2.54 seconds, however, the L-SIGNAL request primitive indicating a break exceeding 
2.54 seconds (break length field value equal to 255) shall be issued at the earliest opportunity following determination 
that the break has exceeded 2.54 seconds. 

The control function shall not issue a subsequent L-SIGNAL request primitive before a prior one has been 
acknowledged by an L-SIGNAL confirmation primitive from the error control function. If Destructive/Expedited or 
Non -destructive/Expedited breaks are being used, and a subsequent break is detected on the DTE interface prior to 
receipt of the L-SIGNAL confirmation primitive associated with a previous break, the DCE may discard and ignore the 
subsequent break. If Non-destructive/Non-expedited breaks are being used, however, subsequent breaks must remain 
pending and signalled following receipt of the L-S1GN AL confirmation primitive associated with any previous break. 

NOTE - Because break signals are not subject to flow control, the buffer capacity of the DCE may be exceeded by the 
receipt of multiple consecutive breaks, resulting in subsequent breaks being discarded. The maximum number of pending non- 
expedited non-destructive breaks which can be accommodated is manufacturer-specific. 

7.5 Receipt of break 

The control function is informed of a break upon receipt of an L-SIGNAL indication primitive. It shall acknowledge this 
primitive with an L-SIGNAL response primitive as soon as possible. Actions to be taken on receipt of the break depend 
on the break-handling option, as shown in Table 5. If a break length is not indicated or contains a zero value, a break of 
default length is delivered to the DTE. 

7.6 Negotiation/Indication of parameter values and optional procedures 

During the protocol establishment phase (see 7.2.2), negotiation and/or indication of parameter values and optional 
procedures is initiated by the control function in the originating DCE if default values are not satisfactory. It may also be 
initiated at any time thereafter by the control function in either DCE. 
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TABLE 4/V.42 

Transmitting DCE actions on receipt of break signal on the V.24 interface 



Rrpnk hanHlintr 

DIVCllV llullUllll^, 

option 


With respect to data 


Going to 
remote DCE 


Going to 
local DTE 


Coming from 
remote DCE 


Coming from 
local DTE 


Destructive/ 
Expedited a) 


- Complete data 
transmission in progress, 
then transmit break 

- Discard data not yet 
transmitted 


- Discard data not yet 
delivered 


- Discard data 
until receive 
acknowledgement 


- Hold data 
until receive 
acknowledgement 


Non-destructive/ 
Expedited 


- Complete data 
transmission in progress, 
then transmit break 

- Hold data until receive 
acknowledgement 


- Continue delivering 
data 


— Continue receiving 
data 


- Continue receiving 
data 


Non-destructive/ 
Non-expedited 


- Wait for acknowledge- 
ment of data previously 
transmitted, and then 
transmit break 

- Hold data until receive 
acknowledgement 


- Continue delivering 
data 


- Continue receiving 
data 


- Continue receiving 
data 


a) All state variables pertaining to control function and error control function operation, except those pertaining to break 
transfer, are reset to their initial values. 



TABLE 5/V.42 

Receiving DCE actions on receipt of break from the remote DCE 



Break handling 
option 


With respect to data 


Going to remote DCE 


Going to local DTE 


Destructive/Expedited a) b) 


- Discard data not yet transmitted 


- Discard data not yet delivered 

- Deliver break signal 


Destructive/Expedited 


- No effect 


- Deliver break signal immediately 

- Resume normal data delivery 


Non-destructive/Non-expedited 


- No effect 


- Deliver break signal in sequence with 
respect to data 


a) All state variables pertaining to control function and error control function operation, except those pertaining to break 
transfer, are reset to their initial values. 

b) For all break options, acknowledgement should be returned as soon as possible. 
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NOTE 1 - The criteria Dy which the control function determines to change parameter values and optional procedures, once 
set during the protocol establishment phase, are beyond the scope of this Recommendation. Examples may include detection of 
changing transmission-line conditions. 



The control function issues an L-SETPARM request primitive to instruct its error control function to initiate negotiation 
and/or indication of parameter values and optional functions. 

Upon receipt of an L-SETPARM indication primitive from its error control function, the control function shall perform 
the necessary negotiation (see clauses 9 and 10). It shall then issue an L-SETPARM response primitive to its error 
control function and complete the negotiation/indication process (see below). 

Upon receipt of an L-SETPARM confirmation primitive from its error control function, the control function completes 
the negotiation/indication process (see below). 

Negotiation/indication of parameter values and optional procedures follow the procedures in clauses 9 and 10. To 
complete the negotiation/indication process, the control function shall set the affected parameters to their new values and 
activate/deactivate the affected procedures. 

NOTE 2 - Some parameters are set independently of and without informing the remote DCE. In such cases, the control 
function sets these parameters to their new values without interacting with the error control function as described above. 



7.7 Orderly release of the error-corrected connection 

After prior establishment of an error-corrected connection, the control function may instruct its error control function to 
release the error-corrected connection in an orderly fashion by issuing an L-RELEASE request primitive. At this time, 
the control function considers the procedure completed. The control function also determines whether to release the 
physical connection. 

NOTE - The stimuli by which the control function orders the error control function to release the error-corrected 
connection in an orderly fashion are beyond the scope of this Recommendation. The control function may disconnect the physical 
connection, without requesting an orderly release of the error-corrected connection, upon detection of the corresponding changes on 
the V.24 interface. 

The control function is informed of an orderly release of the error-corrected connection when it receives an L-RELEASE 
indication primitive from its error control function. The control function may then release the physical connection and 
effect the corresponding changes on the V.24 interface. 



7.8 Loop-back test 

As an optional function agreed to during the protocol establishment phase, a control function may initiate a loop-back 
test with the remote control function. 

NOTE - How a control function determines the need to conduct a loop-back test is for further study. 

To initiate a loop-back test, the control function shall issue an L-TEST request primitive to its error control function. The 
control function is responsible for generating unique data to be returned by the remote control function to indicate a 
successful test. 

A loop-back test may be initiated at any time after completion of the protocol establishment phase. 

The test is considered terminated on receipt of an L-TEST indication primitive containing the data sent with the L-TEST 
request primitive or when a locally-defined period of time has expired. 

A control function receiving an L-TEST indication primitive without having issued a prior L-TEST request primitive 
(i.e. it needs to respond to a loop-back test from the remote control function) shall issue an L-TEST request primitive to 
its error control function. This primitive shall contain the data received in the L-TEST indication primitive to be returned 
to the test initiator. 
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7.9 Operation of the DTE-DCE interface after failure to establish error-correcting operation 

When failure of the detection phase indicates that the remote DCE does not support V.42 error-correcting operation, and 
establishment of any alternative error-correcting capability has also failed, the control function shall either disconnect 
from line, or fall back to non-error-correcting operation and interwork with the remote non-error-correcting DCE 
according to the procedures specified in Recommendation V.14. User-configurable options shall be provided to specify: 

a) whether the DCE should disconnect the line or fall back; and 

b) whether, during fallback operation, the DCE should use buffered or unbuffered operation. 
The method for setting these options is beyond the scope of this Recommendation. 

In unbuffered fallback operation, the DCE operates as specified in Recommendation V.14. No flow control is used 
between the local DCE and DTE, and the data rate of the local DTE/DCE V.24 interface shall be set to match the data 
rate between the DCEs. To avoid data loss and permit correct transfer of data, it is necessary for the DCE to inform 
the DTE of any change in use of flow control and DTE/DCE data rate, but the mechanism for reporting such changes is 
beyond the scope of this Recommendation. 

In buffered fallback operation, the data rate on the local DTE/DCE V.24 interface remains as it would have been in 
error-correcting operation; data is buffered in the DCE, and flow control is used, to match the throughput to the 
DCE/DCE data rate. Break signals shall be transferred in-sequence, non-expedited, and non-destructive with relation to 
buffered data. The DCE provides an internal function to restore any elements removed from the received datastream by 
the remote DCE (according to Recommendation V.14) to accommodate an overspeed condition of the remote DTE. It 
should be noted that flow control of received data should be used with caution as there is a potential for data loss if the 
local DTE asserts flow control to stop the delivery of data from the local DCE for an excessive period of time causing 
the local DCE's receive buffer to overflow. 



8 Operation of the error control function: LAPM procedures 

This clause and Annex A describe the operation of the error control function. 

Within LAPM, all messages are transmitted in frames, which are delimited by opening and closing flags. The frame 
structure and flag pattern are described in 8. 1 . 1 below. 

The procedures in this Recommendation include functions for: 

a) frame delimiting, alignment, and transparency; 

b) transfer of user information (data and break); 

c) sequence control; 

d) detection of transmission, format, and operational errors; 

e) recovery from detected transmission, format, and operational errors with notification of unrecoverable 
errors; 

0 flow control; 

g) negotiation/indication of parameter values and optional procedures; and 

h) initialization and orderly release of the error-corrected connection. 

In addition, LAPM makes provision for one or more "logical" error-corrected connections; discrimination between these 
connections is by means of a Data Link Connection Identifier (DCL1) contained in each frame. 

8.1 General 

This subclause specifies the frame structure and procedures for the proper operation of the Link Access Procedure for 
Modems (LAPM). 
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8.1.1 Frame structure and fields 

8.1.1.1 Frame structure 

All DCE-to-DCE communications are accomplished using the frame structure shown in Figure 4. 

8.1.1.2 Flag sequence and transparency 

All frames are delimited by the unique bit pattern "01 1111 10", known as a flag. The flag preceding the address field is 
^^So^mnt flag The flag following the frame check sequence field is defined as the clos.ng flag. The closing 
flag of one frame may also serve as the opening flag of the next frame. 

Transparency is maintained by the transmitters examining the frame content between the opening and ^"^^ 
inserting a "0" bit after all sequences of five contiguous "1" bits. The receiver examines the frame content between the 
opening and closing flags and discards any "0" bit that directly follows five contiguous "1" bits. 

8.1.1.3 Address field 

The primary purpose of the address field is to identify an error-corrected connection and the error-correcting entity 
associated with it. The format of this field is defined in 8.2.1. 

8.1.1.4 Control field 

The control field is used to distinguish between different frame types. This field is further described in 8.2.2. 



1111 
Opening flag 



Address (Note 1) 



Control (Note 2) 



Information (Note 3) 



FCS 



1 1 
Closing flag 



a) 16-bit FCS 



Octet 1 
2 
3 



N-2 
N-1 



1 1 1 
Opening flag 



Address (Note 1) 



Control (Note 2) 



Information (Note 3) 



FCS 



1 1 
Closing flag 



b) 32-bit FCS 



Octet 1 
2 
3 



N-4 
N-3 
N-2 
N-1 



NOTES 

1 - The maximum size of this field is limited to two octets. 

2 - The control field is two octets for frame types with sequence numbers and one octet for frame types without sequence 
see 8.2.2. 

3 - Not all frame types have an information field 



numbers, 



FIGURE 4/V.42 
Frame structure 
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8.1.1.5 Information field 

Depending on the frame type, an information field may also be present in the frame. The maximum number of octets in 
this field is governed by parameter N401 (see 9.2.3). 

8.1.1.6 Frame Check Sequence (FCS) field 

This field uses a CRC polynomial to guard against bit errors. 

8.1.1.6.1 16-bit frame Check Sequence 

The FCS field shall be the sixteen-bit sequence preceding the closing flag. The 16-bit FCS shall be the ones complement 
of the sum (modulo 2) of 

a) the remainder of x k (x 15 + x 14 + x 13 + x 12 + x 1 1 + x 10 + x 9 + X s + x 1 + x 6 + x 5 + x 4 + x 3 + x 2 + x 1 + 1) 
divided (modulo 2) by the generator polynomial x 16 + x 12 + x 5 + 1, where k is the number of bits in the 
frame existing between, but not including, the final bit of the opening flag and the first bit of the FCS, 
excluding bits inserted for transparency; and 

b) the remainder of the division (modulo 2) by the generator polynomial x 16 -I- x 12 + x 5 + 1 , of the product of 
x 16 by the content of the frame existing between, but not including, the final bit of the opening flag and 
the first bit of the FCS, excluding bits inserted for transparency. 

As a typical implementation at the transmitter, the initial content of the register of the device computing the remainder of 
the division is preset to all Is and is then modified by division by the generator polynomial (as described above) of the 
address, control and information fields; the ones complement of the resulting remainder is transmitted as the sixteen-bit 
FCS. 

As a typical implementation at the receiver, the initial content of the register of the device computing the remainder is 
preset to all Is. The final remainder, after multiplication by x 16 and then division (modulo 2) by the generator 
polynomial x 16 + x 12 + x 5 + 1 of the serial incoming protected bits and the FCS, will be "0001 1 101 0000 1111" 
(x 15 through x°, respectively) in the absence of transmission errors. 

8.1.1.6.2 32-bit frame check sequence 

The FCS shall be the 32-bit sequence preceding the closing flag. The 32-bit FCS shall be the ones complement of 
the sum (modulo 2) of: 

a) the remainder of x* (x 3 1 + x 30 + x 29 + x 28 + x 27 + x 26 + x 25 + x 24 + x 23 + x 22 + x 21 + x 20 + x 19 + x 18 + x 17 + 
x 16 + x 15 + x 14 + x 13 + x 12 + x 1 1 + x 10 + x 9 + x 8 + x 7 + x 6 + x 5 + x 4 + x 3 + x 2 + x 1 + 1 ) divided (modulo 2) 
by the generator polynomial x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 1 1 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x + 1 , 
where k is the number of bits in the frame existing between, but not including, the final bit of the opening 
flag and the first bit of the FCS, excluding bits inserted for transparency; and 

b) the remainder of the division (modulo 2) by the generator polynomial x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + 
x 1 1 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x + 1, of the product of x 32 by the content of the frame existing 
between, but not including, the final bit of the opening flag and the first bit of the FCS, excluding bits 
inserted for transparency. 

As a typical implementation at the transmitter, the initial content of the register of the device computing the remainder of 
the division is preset to all Is and is then modified by division by the generator polynomial (as described above) of the 
address, control and information fields; the ones complement of the resulting remainder is transmitted as the 32-bit FCS. 

As a typical implementation at the receiver, the initial content of the register of the device computing the remainder is 
preset to all Is. The final remainder, after multiplication by x 32 and then division (modulo 2) by the generator 
polynomial x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 1 1 + x 10 + x 8 + x 7 + x 5 -I- x 4 + x 2 + x + 1 of the serial incoming protected 
bits and the FCS, will be "1 100 01 1 1 0000 0100 1 101 1 101 01 1 1 101 1" (x 31 through x°, respectively) in the absence of 
transmission errors. 

8.1.2 Format conventions 

8.1.2.1 Numbering convention 

The basic convention used in this Recommendation is illustrated in Figure 5. The bits are grouped into octets. The bits of 
an octet are shown horizontally and are numbered from 1 to 8. Multiple octets are shown vertically and are numbered 
from 1 to n. 
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8 7 6 5 4 3 2 1 



Octet 1 
2 



FIGURE 5/V.42 
Format convention 



8.1.2.2 Order of bit transmission 

The octets are transmitted in ascending numerical order; inside an octet, bit 1 is the first bit to be transmitted. 

8.1.2.3 Field mapping convention 

When a field is contained within a single octet, the lowest bit number of the field represents the lowest-order value. 

When a field spans more than one octet, the order of bit values within each octet progressively decreases as the octet 
number increases. The lowest bit number associated with the field represents the lowest-order value. 

For example, a bit number can be identified as a couple (o,b) where o is the octet number and b is the relative bit number 
within the octet. Figure 6 illustrates a field that spans from bit (1,3) to bit (2,7). The high-order bit of the field is mapped 
on bit (1,3) and the low-order bit is mapped on bit (2,7). 



8 7 6 5 4 3 2 1 

1st octet of the field 
2nd octet of the field 



FIGURE 6/V.42 
Field mapping convention 





2 4 2 3 2 2 


2 1 2 o 





An exception to the preceding field-mapping convention is the FCS field, which spans two or four octets. In this case, bit 
1 of the first octet is the high-order bit; bit 8 of the second octet (for 16-bit FCS) or bit 8 of the fourth octet (for 32-bit 
FCS) is the low-order bit (see Figure 7). 
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8 7 6 5 4 3 2 1 



2 8 


2 15 


1st octet of the field 


2° 


2 7 


2nd octet of the field 



a) 16-bit FCS 
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2 24 


2 31 


1st octet of the field 


2 16 


2 23 


2nd octet of the field 


2 8 


2 15 


3rd octet of the field 


2° 


2 7 


4th octet of the field 



b) 32-bit FCS 



FIGURE 7/V.42 
FCS mapping convention 



8.1.3 Invalid frames 

An invalid frame is one which: 

a) is not properly bounded by two flags; or 

b) for 16-bit FCS mode, has fewer than five octets between flags of frames that contain sequence numbers 
and fewer than four octets between flags of frames that do not contain sequence numbers; or for 32-bit 
FCS mode, has fewer than seven octets between flags of frames that contain sequence numbers and fewer 
than six octets between flags of frames that do not contain sequence numbers; or 

c) does not consist of an integral number of octets prior to zero-bit insertion or following zero-bit extraction; 
or 

d) contains a frame check sequence error; or 

e) contains an address field with more than two octets or with a DLC1 value not supported by the receiver. 

Invalid frames shall be discarded without notification to the sender (however, see 8.5.4). No action is taken as a result of 
having received the frame. 

8.1.4 Frame abort 

Receipt of seven or more contiguous 1 bits shall be interpreted as an abort and the error control function shall ignore the 
frame currently being received. 

8.1.5 Interframe time fill 

Interframe time fill is accomplished by transmitting contiguous flags between frames, i.e. multiple eight-bit flag 
sequences (see 8. 1 . 1 .2). 

8.2 LAPM elements of procedures and field formats 

The elements of procedures define the commands and responses that are used on an LAPM error-corrected connection. 
Procedures, which are derived from these elements of procedures, are described in subsequent subclauses. 

8.2.1 Address field format 

The format of the address field is shown in Figure 8. The address field contains the data link connection identifier 
(DLC1), the C/R bit, and the address field extension (EA) bit. 

8.2.1.1 Data link connection identifier 

Within the scope of this Recommendation, two DLCI values are defined. One DLC1 value is used to transfer information 
exchanged between V.24 interfaces. The other value, which is optional, is used as a control function-to-control function 
information connection; it is described in clause 1 1 . The value for each DLCI is described in 9.2.7. 
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When using the optional two-octet address field (see 8.2.1.3), the DLCI also includes bits 8 through 2 of octet 2A. 



8 7 6 5 4 3 2 1 



DLCI 


C/R 


EA 


DLCI 


EA 



Octet 2 
2A 



FIGURE 8/V.42 
Address field format 



8.2.1.2 Command/response (C/R) bit field 

The C/R (command/response) bit identifies the frame as either a command or a response. In conformance with HDLC 
rules, a command frame contains the "address" of the error-correcting entity to which it is transmitted while a response 
frame contains the "address" of the error-correcting entity transmitting the frame. For a given error-corrected connec- 
tion, the DLCI value of the address field remains the same but the C/R bit changes, as shown in Table 6. 

TABLE 6/V.42 



Command/response bit usage 



Command/response 


Direction 


C/R value 


Command 


Originator 


> 


Answerer 


1 




Answerer 


> 


Originator 


0 


Response 


Originator 


> 


Answerer 


0 




Answerer 


> 


Originator 


1 



8.2.1.3 Address field extension (EA) bit 

According to the rules of HDLC, the range of the address field may be extended by reserving the first transmitted bit of 
each octet of this field to indicate whether the octet is the last one of the field. Within the scope of this Recommendation, 
the address field is limited to a maximum of two octets. 

When the EA bit is set to 1 in an octet, it signifies that this octet is the last octet of the address field. When the EA bit is 
set to 0, it signifies that another octet of the address field follows. 

8.2.2 Control field format 

The control field identifies the type of frame, which will be a command or response. The control field will contain 
sequence numbers, where applicable. 

Three types of control field formats are specified: numbered information transfer (I format), supervisory functions 
(S format), and unnumbered information transfers and control functions (U format). The control field formats are shown 
in Table 7. 
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8.2.2.1 Information transfer (I) format 



The I format shall be used to perform an information transfer between error-correcting entities. The functions of N(S), 
N(R), and P are independent; that is, each I frame has an N(S) sequence number, an N(R) sequence number that may or 
may not acknowledge additional I frames received by the error-correcting entity, and a P bit that may be set to 0 or 1 . 

8.2.2.2 Supervisory (S) format 

The S format shall be used to perform supervisory control procedures on the error-corrected connection, such as 
acknowledge I frames, request retransmission of one or more I frames, and request temporary suspension of transmission 
of I frames. The functions of N(R) and P/F are independent; that is, each supervisory frame has an N(R) sequence 
number that may or may not acknowledge additional I frames received by the error-correcting entity, and a P/F bit that 
may be set to 0 or 1 . 

8.2.2.3 Unnumbered (U) format 

The U format shall be used to provide additional connection control procedures and unnumbered information transfers. 
The U format does not include sequence numbers but does include a P/F bit that may be set to 0 or 1 . 



TABLE 7/V.42 
Control field formats 



Format 


Control field bits (modulo 128) 
8 7 6 5 4 3 2 1 


1 format 


N(S) 


0 


N(R) 


P 


S format 


X X X X 


S S 


0 1 


N(R) 


P/F 


U format 


M M M P/F 


M M 


1 1 



N(S) Transmitter send sequence number 

N(R) Transmitter receive sequence number 

S Supervisory function bits 

M Modifier function bits 

P/F Poll bit when issued as a command 
Final bit when issued as a response 

X Reserved and set to 0 



8.2.3 Control field parameters and associated state variables 

The various parameters associated with the control field formats are described in this subclause. The coding of the bits 
within these parameters is such that the lowest numbered bit within the parameter field is the least significant bit. 

8.2.3.1 Poll/final (P/F) bit 

All frames contain the poll/final (P/F) bit. The P/F bit serves a function in both command frames and response frames. In 
command frames, the P/F bit is referred to as the P bit. In response frames, it is referred to as the F bit. The P bit set to 1 
is used by an error-correcting entity to solicit (poll) a response frame from the peer error-correcting entity. The F bit set 
to 1 is used by an error-correcting entity to indicate the response frame transmitted as a result of a soliciting (poll) 
command. 
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8.2.3.2 Variables and sequence numbers 

8.2.3.2.1 Modulus 

Each I frame is sequentially numbered and may have the value 0 through n minus 1 (where n is the modulus of the 
sequence numbers). The modulus equals 128 and the sequence numbers cycle through the entire range, 0 through 127. 

NOTE - All arithmetic operations on state variables and sequence numbers contained in this Recommendation are affected 
by the modulus operation. 

8.2.3.2.2 Send state variable V(S) 

Each connection shall have an associated V(S) when using I frame commands. V(S) denotes the sequence number of the 
next I frame to be transmitted. V(S) can take on the value 0 through n minus 1. The value of V(S) shall be incremented 
by 1 with each successive I frame transmission, and shall not exceed V(A) by more than the maximum number of 
outstanding 1 frames, k. The value of k may be in the range of 1 < k < 127. 

8.2.3.2.3 Acknowledge state variable V(A) 

Each connection shall have an associated V(A) when using I frame commands and supervisory frame 
commands/responses. V(A) identifies the last frame that has been acknowledged by its peer (V(A) - 1 equals the N(S) of 
the last acknowledged I frame). V(A) can take on the value 0 through n minus 1 . The value of V(A) shall be updated by 
the valid N(R) values received from its peer (see 8.2.3.2.6). A valid N(R) value is one that is in the 
range V(A) < N(R) < V(S). 

8.2.3.2.4 Send sequence number N(S) 

Only I frames contain N(S), the send sequence number of transmitted I frames. At the time that an in-sequence I frame is 
designated for transmission, the value of N(S) is set equal to V(S). 

8.2.3.2.5 Receive state variable V(R) 

Each connection shall have an associated V(R) when using I frame commands and supervisory frame 
commands/responses. V(R) denotes the sequence number of the next in-sequence I frame expected to be received. V(R) 
can take on the value 0 through n minus 1. The value of V(R) shall be incremented by one with the receipt of an 
error-free, in-sequence 1 frame whose N(S) equals V(R). 

8.2.3.2.6 Receive sequence number N(R) 

All I frames and supervisory frames contain N(R), the expected send sequence number of the next received I frame. At 
the time that a frame of the above types is designated for transmission, the value of N(R) is set equal to V(R). N(R) 
indicates that the error-correcting entity transmitting the N(R) has correctly received all 1 frames numbered up to and 
including N(R) - 1. 

8.2.4 Frame types 

8.2.4.1 Commands and responses 

The command and response frames listed in Table 8 are used by either error-correcting entity. For purposes of the 
LAPM procedures, those frame types not identified in Table 8 are classified as undefined command and/or response 
control fields; the actions to be taken are specified in 8.5.5. 

The commands and responses in Table 8 are defined in 8.2.4.2 through 8.2.4.14. 

8.2.4.2 Information (I) command 

The function of the information (1) command is to transfer, across an error-corrected connection, sequentially numbered 
frames containing data received from the V.24 interface and provided by the control function. 

8.2.4.3 Set asynchronous balanced mode extended (SABME) command 

The SABME unnumbered command is used to place the addressed error-correcting entity into the connected state. 

No information field is permitted with the SABME command. An error-correcting entity confirms acceptance of an 
SABME command by the transmission at the first opportunity of a UA response. Upon acceptance of this command, the 
error-correcting entity's V(S), V(A), and V(R) are set to 0. The transmission of an SABME command indicates the 
clearance of all exception conditions. 
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Previously-transmitted 1 frames that are unacknowledged when this command is processed remain unacknowledged and 
are discarded. 

8.2.4.4 Disconnect (DISC) command 

The DISC unnumbered command is used to return to the disconnected state. 

No information field is permitted with the DISC command. The error-correcting entity receiving the DISC command 
confirms the acceptance of a DISC command by the transmission of a UA response. The error-correcting entity sending 
the DISC command terminates the error-corrected connection when it receives the acknowledging UA or DM response. 

Previously-transmitted 1 frames that are unacknowledged when this command is processed remain unacknowledged and 
are discarded. 
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8.2.4.5 Unnumbered information (UI) command/response 

Unnumbered information (UI) frames are used to convey control information outside the DTE information stream, 
which is carried by I frames. This control information may be associated with the DTE's information stream (e.g. a 
break signal). No sequence numbers are contained within the control field of a UI frame. The P/F bit of a UI frame is set 
to 0. 

The encoding of this information field is given in 12.3. 

8.2.4.6 Receive ready (RR) command/response 

The RR supervisory frame is used by an error-correcting entity to: 

a) indicate it is ready to receive an I frame; 

b) acknowledge previously received 1 frames numbered up to and including N(R) - 1 (as defined in 8.4.3.1); 
and 

c) clear a busy condition that was indicated by the earlier transmission of an RNR frame by that same error- 
correcting entity. 

In addition to indicating the status of an error-correcting entity, the RR command with the P bit set to 1 may be used by 
the error-correcting entity to ask for the status of its peer error-correcting entity. 

8.2.4.7 Reject (REJ) command/response 

The REJ supervisory frame is used by an error-correcting entity to request retransmission of I frames starting with 
the frame numbered N(R). The value of N(R) in the REJ frame acknowledges 1 frames numbered up to and including 
N(R) - I. New I frames pending initial transmission shall be transmitted following the retransmitted 1 frame(s). 

Only one REJ exception condition for a given direction of information transfer is established at a time. The REJ 
exception condition is cleared (reset) upon the receipt of an I frame with an N(S) equal to the N(R) of the REJ frame. 

The transmission of an REJ frame shall also indicate the clearance of any busy condition within the sending error- 
correcting entity that was reported by the earlier transmission of an RNR frame by that same error-correcting entity. 

In addition to indicating the status of an error-correcting entity, the REJ command with the P bit set to 1 may be used by 
the error-correcting entity to ask for the status of its peer error-correcting entity. 

8.2.4.8 Selective reject (SREJ) 

8.2.4.8.1 Selective reject (SREJ) command/response (for use with s-SREJ procedure) 

Implementation of the single-Selective Reject (s-SREJ) procedure is optional; if implemented it shall use the SREJ frame 
as described here. When implemented, it is used by an error-correcting entity to request retransmission of the single I 
frame numbered N(R). The P/F bit of a SREJ frame is always set to 0. In this case, the N(R) of the SREJ frame does not 
indicate acknowledgement of any I frames. 

Each SREJ exception condition is cleared upon receipt of the I frame with an N(S) equal to the N(R) of the SREJ frame. 
An error-correcting entity may transmit one or more SREJ frames, each containing a different N(R), with the P/F bit set 
to 0 before one or more earlier SREJ exception conditions have been cleared. 

I frames that may have been transmitted following the I frame indicated by the SREJ frame shall not be retransmitted as 
the result of receiving an SREJ frame. Additional I frames awaiting initial transmission may be transmitted following the 
retransmission of the specific I frame requested by the SREJ frame. 

8.2.4.8.2 Selective reject (SREJ) response (for use with m-SREJ) 

Implementation of the multi-Selective Reject (m-SREJ) procedure is optional; if implemented it shall use the SREJ 
response frame as described here. When implemented, it is used by an error-correcting entity to initiate error recovery by 
requesting retransmission of one or more (not necessarily contiguous) lost I frames. The N® field of the control field of 
the SREJ frame shall contain the sequence number of the earliest I frame to be retransmitted and the information field 
shall contain the sequence numbers of additional I frames(s), if any, in any, in need of retransmission. 
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The error-correcting entity shall create a list of sequence numbers N(X), N(X)+1, N(X)+2, N(Y), N(Z)+3, N(Z)+4, 
N(S)-U where N(X) is greater than or equal to V(R) and none of the I frames N(X) to N(S)-1 have been received. The 
N(R) field of the SREJ frame shall be set to N(X) and the information field set to the list N(X)+1, N(S)-1. The 
information field shall be encoded such that there is one octet for each 1 frame in need of retransmission. The sequence 
number of each designated I frame shall occupy bit positions 2-8 of an octet, as depicted in Figure 9. 

If the list of sequence numbers is too large to fit in the information field of the SREJ frame, then the list shall be 
truncated to fit in one SREJ frame, by including only the earliest sequence numbers. The truncated sequence number 
may be transmitted in another SREJ frame. The number of bits in the information field of an SREJ frame shall not 
exceed the value of parameter N401 , the maximum number of octets in the information field of a frame. 

If the F bit in an SREJ frame is set to 1, then I frames numbered up to N(RH inclusive are considered as acknowledged. 
If the F bit in an SREJ frame is set to 0, then the N(R) in the control field of the SREJ frame does not indicate 
acknowledgment of I frames. 

Each SREJ exception condition is cleared upon receipt of the I frame(s) with an N(R) identified in the SREJ frame 
control field and, if present, information field. An error-correcting entity may transmit one or more SREJ response 
frames with their F bit set to 0, each containing one or more different N(R) values before earlier exception conditions 
have been cleared. 

1 frames that may have been transmitted following an I frame indicated in an SREJ frame shall not be transmitted as the 
result of receiving an SREJ frame. Additional I frames awaiting initial transmission may be transmitted following the 
retransmission of a specific I frame(s) requested by an SREJ frame. 
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NOTES 

1 - The maximum size of this field is limited to 2 octets. 

2 - The FCS field can be either 16 bits or 32 bits in length. 



FIGURE 9/V.42 

Control and information field encoding of SREJ frame for m-SREJ procedure 



8.2.4.9 Receive not ready (RNR) command/response 

The RNR supervisory frame is used by an error-correcting entity to indicate a busy condition; that is, a temporary 
inability to accept additional incoming I frames. The value of N(R) in the RNR frame acknowledges I frames numbered 
up to and including N(R) - 1 . 

In addition to indicating the status of an error-correcting entity, the RNR command with the P bit set to 1 may be used by 
the error-correcting entity to ask for the status of its peer error-correcting entity. 
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8.2.4.10 Unnumbered acknowledgement (UA) response 

The UA unnumbered response is used by an error-correcting entity to acknowledge the receipt and acceptance of the 
mode-setting commands (SABME or DISC). Received mode-setting commands are not processed until the UA response 
is transmitted. No information field is permitted with the UA response. The transmission of the UA response indicates 
the clearance of any busy condition that was reported by the earlier transmission of an RNR frame by that same error- 
correcting entity. 

8.2.4.11 Disconnected mode (DM) response 

The DM unnumbered response is used by an error-correcting entity to report to its peer that the error-correcting entity is 
in the disconnected state and/or unable or unwilling to enter the connected state. No information field is permitted with 
the DM response. For specific information on the handling of receiver DM frames, see Table 9 and 8.9.3. 

8.2.4.12 Frame reject (FRMR) response 

The FRMR unnumbered response may be received by an error-correcting entity as a report of an error condition not 
recoverable by retransmission of the identical frame, i.e. at least one of the following error conditions resulting from the 
receipt of a valid frame: 

a) the receipt of a command or response control field that is undefined or not implemented; 

b) the receipt of a supervisory or unnumbered frame with incorrect length; 

c) the receipt of an invalid N(R); or 

d) the receipt of a frame with an information field which exceeds the maximum established length. 
An undefined control field is any of the control-field encodings not identified in Table 8. 

A valid N(R) value is one that is in the range V(A) < N(R) < V(S). 

An information field which immediately follows the control field and consists of five octets is returned with this 
response and provides the reason for the FRMR response. This information field format is given in Figure 10. 

8.2.4.13 Exchange identification (XID) command/response 

XID frames are used to exchange general identification information. No sequence numbers are contained within the 
confrol field of an XID frame. The P/F bit of an XID frame is set to 0. 

Within the scope of this Recommendation, the information field of XID frames is used for negotiation/indication of 
parameter values and optional procedures. The encoding of this information field is given in 12.2. 

8.2.4.14 Test (TEST) command 

Implementation of the TEST command frame is optional. When implemented, it is used to conduct a loop-back test 
between the two control functions. No sequence numbers are contained within the control field of a TEST frame. The 
P bit of a TEST command frame is set to 0. 

An information field, not specified by this Recommendation, is also included in the frame. The control function 
initiating a loop-back test chooses the contents of the information field. The control function responding to a loop-back 
test returns the information field received from the initiator. 

8.2.5 Use of timers 

For various functions in the following subclauses, timers are used to ensure proper operation of the protocol. In these 
subclauses, the following terminology is used to describe timer operations: 

a) to start or restart a timer both imply that the timer is set to run from a predefined value; 

b) to stop a timer implies that it no longer runs and that the value of the timer at the time it is stopped is of no 
significance. 
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8.3 Establishment of the error-corrected connection 
8.3.1 General 

The procedures in this subclause are used to establish the error-corrected connection (i.e. go from a disconnected to a 
connected state) to allow the transfer of user data from V.24 interface to V.24 interface. 

On receipt of an L-ESTABLISH request primitive from its control function, the error control function shall attempt to 
establish the error-corrected connection. The error-correcting entity transmits an SABME frame. All frames other than 
unnumbered format frames received at this time shall be ignored. 
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NOTES 



1 - Rejected frame control field is the control field of the received frame which caused the frame reject. When 
the rejected frame is an unnumbered frame, the control field of the rejected frame is positioned in octet 4, with 
octet 5 set to 00000000. 

2 - V(S) is the current send state variable value of the error-correcting entity reporting the rejection condition. 

3 - C/R is set to 1 if the frame rejected was a response and is set to 0 if the frame rejected was a command. 

4 - V(R) is the current receive state variable value of the error-correcting entity reporting the rejection 
condition. 

5 - W set to 1 indicates that the control field received and returned in octets 4 and 5 was undefined or not 
implemented. 

6 - X set to 1 indicates that the control field received and returned in octets 4 and 5 was considered invalid 
because the frame contained an information field which is not permitted with this frame or is a supervisory or 
unnumbered frame with incorrect length. Bit W must be set to 1 in conjunction with this bit. 

7 - Y set to 1 indicates that the information field received exceeded the maximum established information 
field length (N401) of the error-correcting entity reporting the rejection condition. 

8 - Z set to 1 indicates that the control field received and returned in octets 4 and 5 contained an invalid N(R). 

9 - Octet 6, bit 1 and octet 8, bits 5 through 8 shall be set to 0. 



FIGURE 10/V.42 
FRMR information field format 



8.3.2 Detailed procedures 
8.3.2.1 Establishment procedures 

A request to establish the error-corrected connection is initiated by the transmission of the SABME command. All 
existing exception conditions shall be cleared, the retransmission counter shall be reset, and timer T401 shall then be 
started (timer T401 is defined in 9.2. 1). 

NOTE 1 - To avoid misinterpretation of a received DM response frame, the SABME frame shall always be transmitted 
with its P bit set to 1. 
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NOTE 2 - When sending the above frame as the first protocol frame following the detection phase (if used) or 
establishment of the physical connection (if the detection phase is not used), the originator shall first transmit flag patterns for a period 
of time sufficient to guarantee the transmission of at least 16 flag patterns. 



An error-correcting entity receiving an SABME command, if it is able to establish the error-corrected connection (as 
indicated by receipt of an L-ESTABLISH response primitive from the control function in response to an L-ESTABL1SH 
indication primitive), shall: 

- respond with a UA response with the F bit set to the same binary value as the P bit in the received 
SABME command; 

- set V(S), V(R), and V(A) to 0; 

- consider the error-corrected connection as established and enter the connected state; 

- clear all existing exception conditions; 

clear any existing peer-receiver busy condition; and 

- start timer T403 (timer T403 is defined in 9.2.6) if implemented. 

NOTE 3 - When a repeated SABME frame is received during link establishment, indicating that the originating DCE may 
not have received the UA response, any unacknowledged I frames remain unacknowledged with respect to the error control function. 
Responsibility for the contents of the information fields of such I frames reverts to the control function. Whether or not the contents of 
these information fields are reassigned to the error control function is decided by the control function. 

If the control function is unable to accept establishment of the error-corrected connection (as indicated by an 
L-RELEASE request primitive from the control function in response to an L-ESTABLISH indication primitive), the 
error-correcting entity shall respond to the SABME command with a DM response with the F bit set to the same binary 
value as the P bit in the received SABME command. 

Upon reception of the UA response with the F bit set to I, the originator of the SABME command shall: 

- stop timer T401; 

- start timer T403 if implemented; 

- set V(S), V(R), and V(A) to 0; and 

- consider the error-corrected connection as established (i.e. enter the connected state) and inform the 
control function by using the L-ESTABLISH confirmation primitive. 

Upon reception of a DM response with the F bit set to 1, the originator of the SABME command shall inform its control 
function of a failure to establish the error-corrected connection (by issuing an L-RELEASE indication primitive) and 
stop timer T401 . DM responses with the F bit set to 0 shall be ignored in this case. 

Upon receipt of an I frame or a supervisory frame, the originator of the SABME command may assume that the 
responding error-correcting entity has received and accepted the SABME command and sent a UA response, but that the 
UA response was lost in transmission. It may proceed as though a UA response has been received, and perform the 
actions noted above for reception of the UA response before processing the received I frame or supervisory frame. 

8.3.2.2 Procedure on expiry of timer T401 

If timer T401 expires before the U A or DM response with the F bit set to 1 is received, the error-correcting entity shall: 
retransmit the SABME command as above; 
restart timer T40 1 ; and 
increment the retransmission counter (N400). 

After retransmission of the SABME command N400 times and failure to receive a response, the error-correcting entity 
shall indicate this to the control function by means of the L-RELEASE indication primitive. Any data in queue shall be 
discarded. 

The value of N400 is defined in 9.2.2. 



26 Recommendation V.42 (10/96) 



8.4 Transfer of user data from the V,24 interface 

Having either transmitted the UA response to a received SABME command or received the UA response to a transmitted 
SABME command, information transfer may commence. This subclause deals with the transfer of user data from the 
V.24 interface. Subclause 8.6 deals with the transfer of control information. 

8.4.1 Transmitting I frames 

Data received by the error-correcting entity from the control function by means of an L-DATA request primitive shall be 
transmitted in an I frame. The control field parameters N(S) and N(R) shall be assigned the values V(S) and V(R), 
respectively. V(S) shall be incremented by 1 at the end of the transmission of the 1 frame. 

If timer T401 is not running at the time of transmission of an 1 frame, it shall be started. If timer T401 expires, the 
procedures defined in 8.4.8 shall be followed. 

If V(S) is equal to V(A) plus k (where k is the maximum number of outstanding I frames - see 9.2.4), the error- 
correcting entity shall not transmit any new I frames, but may retransmit an I frame as a result of the error-recovery 
procedures as described in 8.4.4 and 8.4.5. 

When an error-correcting entity is in an own-receiver busy condition, it may still transmit 1 frames, provided that a peer- 
receiver busy condition does not exist. 

NOTE - L-DATA request primitives received while in the timer-recovery condition (see 8.5.3) shall be queued. 

8.4.2 Receiving I frames 

Independent of a timer-recovery condition, when an error-correcting entity is not in an own-receiver busy condition and 
receives a valid I frame whose N(S) is equal to the current V(R), the error-correcting entity shall: 

pass the information field of this frame to the control function using the L-DATA indication primitive; 

increment by 1 its V(R) and act as indicated below. 

8.4.2.1 P bit set to 1 

If the P bit of the received 1 frame was set to 1, the error-correcting entity shall respond to its peer in one of the 
following ways: 

if the error-correcting entity receiving the 1 frame is still not in an own-receiver busy condition, it shall 
send an RR response with the F bit set to 1 ; 

if the error-correcting entity receiving the I frame enters the own-receiver busy condition upon receipt of 
the I frame, it shall send an RNR response with the F bit set to 1 . 

8.4.2.2 P bit set to 0 

If the P bit of the received I frame was set to 0 and: 

a) if the error-correcting entity is still not in an own-receiver busy condition: 

if no 1 frame is available for transmission or if an 1 frame is available for transmission but a peer- 
receiver busy condition exists, the error-correcting entity shall transmit an RR response with the F bit 
set to 0; or 

if an 1 frame is available for transmission and no peer-receiver busy condition exists, the error- 
correcting entity shall transmit the I frame with the value of N(R) set to the current value of V(R) as 
defined in 8.4.1; or 

b) if, on receipt of this 1 frame, the error-correcting entity is now in an own-receiver busy condition, it shall 
transmit an RNR response with the F bit set to 0. 

When the error-correcting entity is in an own-receiver busy condition, it shall process any received 1 frame according 
to 8.4.7. 
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8.4.3 Sending and receiving acknowledgements 

8.4.3.1 Sending acknowledgements 

Whenever an error-correcting entity transmits an I frame or an RR, RNR, or REJ supervisory frame, N(R) shall be set 
equal to V(R). 

8.4.3.2 Receiving acknowledgements 

On receipt of a valid I frame or an RR, RNR, or REJ supervisory frame, even in the own-receiver busy or the timer 
recovery condition, the error-correcting entity shall treat the N(R) contained in this frame as an acknowledgement for all 
the I frames it has transmitted with an N(S) up to and including the received N(R) - 1. V(A) shall be set to N(R). The 
error-correcting entity shall stop the timer T401 on receipt of a valid 1 frame or an RR, RNR, or REJ supervisory frame 
with the N(R) higher than V(A) (actually acknowledging some I frames), or an REJ frame with an N(R) equal to V(A). 
The error-correcting entity shall stop the timer T401 on receipt of an SREJ supervisory frame with an N(R) equal to or 
higher than V(A), even though there is no acknowledgement function associated with the N(R) contained in the SREJ 
frame. 

NOTES 

1 - If an RR, RNR, or REJ supervisory frame with P bit set to 1 has been transmitted and not acknowledged, timer T401 
shall not be stopped. 

2 - Upon receipt of a valid I frame, timer T401 shall not be stopped if the error-correcting entity is in the peer-receiver 
busy condition (i.e. the remote error-correcting entity had indicated a busy condition). 

If timer T401 has been stopped by the receipt of an I, RR, or RNR frame, and if there are outstanding I frames still 
unacknowledged, the error-correcting entity shall restart timer T401. If timer T401 then expires, the error-correcting 
entity shall follow the recovery procedure as defined in 8.4.8 with respect to the unacknowledged I frames. 

If timer T401 has been stopped by the receipt of an REJ frame, the error-correcting entity shall follow the retransmission 
procedures in 8.4.4. 

If timer T401 has been stopped by the receipt of an SREJ frame, the error-correcting entity shall follow the selective 
retransmission in 8.4.5 and start timer T401. If timer T401 then expires, the error-correcting entity shall follow the 
recovery procedure defined in 8.4.8 with respect to the unacknowledged I frames. 

8.4.4 Receiving REJ frames 

On receipt of a valid REJ frame, the error-correcting entity shall act as follows: 

a) if it is not in the timer-recovery condition: 

- clear an existing peer-receiver busy condition; 

set its V(S) and its V(A) to the value of the N(R) contained in the REJ frame control field; 
stop timer T401; 

- start timer T403 if implemented; 

if it was an REJ command frame with the P bit set to 1, transmit an appropriate supervisory response 
frame (see Note 2 in 8.4.6) with the F bit set to 1 ; 

transmit the corresponding I frame as soon as possible, as defined in 8.4.1, taking into account 
items 1) to 3) below and the paragraph following items 1) to 3); and 

note that a protocol violation has occurred if the received frame was an REJ response frame with the 
F bit set to 1 ; 

b) if it is in the timer- recovery condition and it was an REJ response frame with the F bit set to 1 : 

- clear an existing peer-receiver busy condition; 

- set its V(S) and its V(A) to the value of the N(R) contained in the control field of the REJ frame; 

- stop timer T401; 

start timer T403 if implemented; and 

- transmit the corresponding I frame as soon as possible, as defined in 8.4.1, taking into account 
items 1) to 3) below and the paragraph following items 1) to 3); 
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c) if it is in the timer-recovery condition and it was an REJ frame other than an REJ response frame with the 
F bit set to 1 : 

clear an existing peer-receiver busy condition; 

set its V(A) to the value of the N(R) contained in the control field of the REJ frame; and 

- if it was an REJ command frame with the P bit set to 1 , transmit an appropriate supervisory response 
frame with the F bit set to 1 (see Note 2 in 8.4.6). 

Transmission of 1 frames shall take account of the following: 

1) if the error-correcting entity is transmitting a supervisory frame when it receives the REJ frame, it shall 
complete that transmission before commencing transmission of the requested I frame; 

2) if the error-correcting entity is transmitting an SABME command, a DISC command, a UA response, or a 
DM response when it receives the REJ frame, it shall ignore the request for retransmission; and 

3) if the error-correcting entity is not transmitting a frame when the REJ is received, it shall immediately 
commence transmission of the requested 1 frame. 

All outstanding unacknowledged I frames, commencing with the 1 frame identified in the received REJ frame shall be 
transmitted. Other 1 frames not yet transmitted may be transmitted following the retransmitted 1 frames. 

8.4.5 Receiving SREJ frames 
8.4.5.1 Single-SREJ procedure 

If the optional selective retransmission procedure has been agreed for use on the error-corrected connection, then receipt 
of an SREJ frame results in the retransmission of the I frame whose N(S) is equal to the N(R) in the SREJ frame. No 
other 1 frames shall be retransmitted as a result of receiving the SREJ frame (however, 1 frames pending initial 
transmission may be transmitted). 

Transmission of I frames shall take account of the following: 

1) if the error-correcting entity is transmitting a supervisory frame when it receives the SREJ frame, it shall 
complete that transmission before commencing transmission of the requested 1 frame; 

2) if the error-correcting entity is transmitting an SABME command, a DISC command, a UA response, or a 
DM response when it receives the SREJ frame, it shall ignore the request for retransmission; and 

3) if the error-correcting entity is not transmitting a frame when the SREJ is received, it shall immediately 
commence transmission of the requested I frame. 

If the optional selective retransmission procedure has not been agreed for use, then receipt of an SREJ frame shall be 
treated as an unrecognized command/response control field (see 8.5.5). 

8.4.5.2 Multi-SREJ procedure 

8.4.5.2.1 SREJ response frame with F bit set to 0 

When receiving an SREJ response frame with its F bit set to 0, the error-correcting entity shall retransmit all I frames 
whose sequence numbers are indicated in the N(R) field and the information field of the SREJ frame, in the order 
specified in the SREJ frame. Retransmission shall conform to the following: 

a) If the error-correcting entity is transmitting a supervisor or I frame when it receives the SREJ frame, it 
shall complete that transmission before commencing transmission of the requested I frame(s) 

b) If the error-correcting entity is transmitting an unnumbered command or response when it receives the 
SREJ frame, it shall ignore the request for retransmission. 

c) If the error-correcting entity is not transmitting any frame when it receives the SREJ frame, it shall 
commence transmission of the requested 1 frames immediately. 

If there is no outstanding poll condition, then a poll shall be sent either by transmitting an RR command (or RNR 
command if the error-correcting entity is in the busy condition) with the P bit set to 1 or by setting the P bit in the last 
retransmitted I frame and timer T401 shall be restarted. 

If there is an outstanding poll condition, then timer T401 shall not be restarted. 
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8.4.5.2.2 SREJ resp nse frame with F bit set to 1 

When receiving an SREJ response frame with its F bit set to 1, the error-correcting entity shall retransmit all I frames 
whose sequence numbers are indicated in the N(R) field and the information field of the SREJ frame, in the order 
specified in the SREJ frame, except those I frames that were sent subsequent to the frame with the P bit set to 1 was sent. 
Retransmission shall conform to the following: 

a) If the error-correcting entity is transmitting a supervisory or I frame when it receives the SREJ frame, it 
shall complete that transmission before commencing transmission of the requested 1 frames. 

b) If the error-correcting entity is transmitting an unnumbered command or response when it receives the 
SREJ frame, it shall ignore the request for retransmission. 

c) If the error-correcting entity is not transmitting any frame when it receives the SREJ frame, it shall 
commence transmission of the requested 1 frames immediately. 

If any frames are retransmitted, then a poll shall be sent either by transmitting an RR command (or RNR command if the 
error-correcting entity is in the busy condition) with the P bit set to 1 or by setting the P bit in the last retransmitted 
I frame. 

Timer T401 shall be restarted. 
8.4.6 Receiving RNR frames 

After receiving a valid RNR command or response, if the error-correcting entity is not engaged in a mode-setting 
operation (i.e. not transmitting an SABME or DISC frame), it shall set a peer-receiver busy condition and then: 

if it was an RNR command with the P bit set to 1 , it shall respond with an RR response with the F bit 
set to 1 if the error-correcting entity is not in an own-receiver busy condition, and shall respond with 
an RNR response with the F bit set to 1 if the error-correcting entity is in an own-receiver busy 
condition; and 

if it was an RNR response with the F bit set to 1, an existing timer-recovery condition shall be 
cleared and the N(R) contained in this RNR response shall be used to update V(S). 

The error-correcting entity shall take note of the peer-receiver busy condition and not transmit any I frames to the remote 
error-correcting entity. 

NOTE 1 - The N(R) in any RR or RNR command frame (irrespective of the setting of the P bit) will not be used to update 
the send state variable V(S). 

The error-correcting entity shall then: 

treat the N(R) contained in the received RNR frame as an acknowledgement for all the I frames that have 
been (re)transmitted with an N(S) up to and including N(R) - 1, and set its V(A) to the value of the N(R) 
contained in the RNR frame; and 

restart timer T401 unless a supervisory response frame with F bit set to 1 is still expected. 

If timer T401 expires, the error-correcting entity shall: 

if it is not yet in a timer-recovery condition, enter the timer-recovery condition and reset the retrans- 
mission count variable; or 

if it is already in a timer-recovery condition, add one to its retransmission count variable. 

The error-correcting entity shall then: 

a) if the value of the retransmission count variable is less than N400: 

- transmit an appropriate RR, RNR, or REJ supervisory command (see Note 2) with P bit set to 1; 
restart timer T40 1 ; and 

b) if the value of the retransmission count variable is equal to N400, initiate a re-establishment procedure as 
defined in 8.4.9. 
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The error-correcting entity receiving the RR, RNR, or REJ supervisory frame with the P bit set to 1 shall respond, at the 
earliest opportunity, with an RR, RNR, or REJ supervisory response frame (see Note 2) with the F bit set to 1 to indicate 
whether or not its own-receiver busy condition still exists. 

Upon receipt of a supervisory response with F bit set to 1 , the error-correcting entity shall stop timer T401 , and: 

if the response is an RR or REJ or SREJ response, the peer-receiver busy condition is cleared and the 
error-correcting entity may transmit new I frames or retransmit 1 frames as defined in 8.4.1 or 8.4.4, 
respectively; or 

if the response is an RNR response, the error-correcting entity receiving the response shall proceed 
according to the first paragraph of this subclause. 

If a supervisory command (RR, RNR, or REJ) with the P bit set to 0 or 1, or a supervisory response frame (RR, RNR, 
or REJ) with the F bit set to 0 is received during the enquiry process, the error-correcting entity shall: 

if the supervisory frame is an RR or REJ command frame or an RR, REJ or an SREJ response frame, 
clear the peer-receiver busy condition and if the supervisory frame received was a command with the P bit 
set to 1, transmit the appropriate supervisory response frame (see Note 2) with the F bit set to 1. However, 
the transmission or retransmission of 1 frames shall not be undertaken until the appropriate supervisory 
response frame with the F bit set to 1 is received or until the expiry of timer T401 ; or 

if the supervisory frame is an RNR command frame or an RNR response frame, retain the peer-receiver 
busy condition and if the supervisory frame received was an RNR command with P bit set to 1, transmit 
the appropriate supervisory response frame (see Note 2) with the F bit set to 1 . 

NOTE 2 - If the error-correcting entity is not in an own-receiver busy condition and is in a reject-exception 
condition [that is, an N(S) sequence error has been detected and an REJ frame has been transmitted, but the requested 
I frame has not been received], the appropriate supervisory frame is the RR frame. 

if the error-correcting entity is not in an own-receiver busy condition but is in an N(S) sequence error 
exception condition [that is, an N(S) sequence error has been detected but an REJ frame has not been 
transmitted], the appropriate supervisory frame is the REJ frame; 

if the error-correcting entity is in its own-receiver busy condition, the appropriate supervisory frame is the 
RNR frame; 

otherwise, the appropriate supervisory frame is the RR frame. 
8.4.7 Own-receiver busy condition 

When the error-correcting entity enters an own-receiver busy condition, it shall transmit an RNR frame at the earliest 
opportunity. 

The RNR frame may be either: 

an RNR frame with the F bit set to 0; or 

if this condition is entered on receiving a command frame with the P bit set to 1, an RNR response with 
the F bit set to 1 ; or 

if this condition is entered on expiry of timer T401 , an RNR command with the P bit set to 1 . 
All received I frames with the P bit set to 0 shall be discarded, after updating V(A). 

All received RR, RNR, and REJ supervisory frames with the P/F bit set to 0 shall be processed, including 
updating V(A). 

All received SREJ supervisory frames with the P/F bit set to 0 shall be processed as specified in 8.4.5. 

All received I frames with the P bit set to 1 shall be discarded, after updating V(A). However, an RNR response frame 
with the F bit set to 1 shall be transmitted. 

All received RR, RNR, and REJ supervisory frames with the P bit set to 1 shall be processed, including updating V(A). 
An RNR response with the F bit set to 1 shall be transmitted. 
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To indicate to the peer error-correcting entity the clearance of the own-receiver busy condition, the error-correcting 
entity shall transmit an RR frame or, if a previously-detected N(S) sequence error has not yet been reported, an REJ 
frame with its N(R) set to the current value of V(R) or an SREJ frame (if agreed for use). 

8.4.8 Waiting acknowledgement 

The error-correcting entity shall maintain an internal retransmission count variable. 

If timer T401 expires, the error-correcting entity shall: 

if it is not yet in the timer-recovery condition, enter the timer-recovery condition and reset the 
retransmission count variable; or 

if it is already in the timer-recovery condition, add one to its retransmission count variable. 

The error-correcting entity shall then: 

a) if the value of the retransmission count variable is less than N400, restart/timer T401 and transmit an 
appropriate supervisory command (see Note 2 in 8.4.6) with the P bit set to 1 ; or 

b) if the value of the retransmission count variable is equal to N400, initiate a termination procedure as 
defined in 8.4.9. 

The time-recovery condition is cleared when the error-correcting entity receives a valid supervisory response frame with 
the F bit set to 1. If the received RR, RNR, or REJ supervisory frame N(R) is within the range from its current V(A) to 
its current V(S), inclusive, it shall set its V(S) to the value of the received N(R). If the received SREJ supervisory frame 
N(R) is within the range from the current V(A) to V(S), inclusive, it shall follow the procedures outlined in 8.4.5.2.1 or 
8.4.5.2.2 depending on the setting of the F bit. Timer T401 shall be stopped if the received supervisory frame response is 
an RR or REJ response, and then the error-correcting entity shall resume with I frame transmission or retransmission, as 
appropriate. Timer T401 shall be stopped and restarted if the received supervisory response is an RNR response, to 
proceed with the enquiry process according to 8.4.6. 

8.4.9 Termination of the error-corrected connection 

8.4.9.1 Criteria for termination 

The criteria for termination of an error-corrected connection are defined in this subclause by the following conditions: 

- the receipt, while in the connected state, of an SABME except that an answering error-correcting entity 
shall accommodate the possibility that the originating error-correcting entity may retransmit an SABME 
during initial link establishment if the UA response is lost in transmission; 

- the occurrence of N400 retransmission failures while in the timer recovery condition (see 8.4.8); 
the occurrence of a frame-rejection condition as identified in 8.5.5; 

the receipt, while in the connected state, of an FRMR response frame (see 8.5.6); 

- the receipt, while in the connected state, of an unsolicited DM response with the F bit set to 0 (see 8.5.7); 
the receipt, while in the timer recovery condition, of a DM response with the F bit set to 1 . 

8.4.9.2 Procedures 

In all termination situations, an L-RELEASE indication primitive shall be passed to the control function, and the 
disconnected state shall be entered. The control function shall cause the immediate release of the physical connection. 

8.5 Exception condition reporting and recovery 

Exception conditions may occur as the result of errors on the physical connection or procedural errors by an error- 
correcting entity. 

The error-recovery procedures that are available to effect recovery following the detection of an exception condition by 
an error-correcting entity are defined in this subclause. 
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8.5.1 N(S) sequence error 

An N(S) sequence error exception condition occurs in the receiver when a valid I frame is received containing an N(S) 
value that is not equal to the V(R) at the receiver. Methods for recovering from N(S) sequence error exception 
conditions are: 

a) use of REJ frames (mandatory); 

b) use of SREJ frames - single frame (s-SREJ) recovery (optional and requires negotiation, see clause 10); 

c) use of SREJ frames - multiple frame (m-SREJ) recovery (optional and requires negotiation, see 
clause 10) 

The action of the receiver depends on whether or not the optional selective-retransmission procedure has been agreed for 
use on the error-corrected connection. If it has, the information field of 1 frames whose N(S) is not equal to the V(R) at 
the receiver shall be held for subsequent delivery to the control function until the expected 1 frame [i.e. the I frame with 
its N(S) = V(R)] is received. If the selective- retransmission procedure has not been agreed for use, the information field 
of all 1 frames whose N(S) does not equal the V(R) shall be discarded. 

In either case, the receiver shall not acknowledge [nor increment its V(R)] the I frame causing the sequence error, nor 
any 1 frames which may follow, until an I frame with the correct N(S) is received. 

An error-correcting entity that receives one or more 1 frames having sequence errors but which are otherwise error-free, 
or subsequent supervisory frames, shall use N(R) and P/F bit setting contained in the control field to perform 
connection-control functions; for example, to receive acknowledgement of previously-transmitted I frames and to cause 
the error-correcting entity to respond if the P bit is set to 1. Therefore, the retransmitted 1 frame may contain an N(R) 
value and P bit that are updated from, and therefore different from, the ones contained in the originally transmitted I 
frame. 

Either the REJ frame or the SREJ frame (either for the s-SREJ procedure or the m-SREJ procedure) is used by the 
receiving error-correcting entity to initiate an exception condition recovery (retransmission) following the detection of 
an N(S) sequence error. 

For a given direction of information transfer: 

only one REJ exception condition shall be established at a time; 

when using the s-SREJ procedure, any number of SREJ exception conditions may be established at a 
time; 

when using the m-SREJ procedure, any number of SREJ exception conditions with F=0 may be 
established at a time; only one SREJ condition with F=l, in response to a poll, may be established. 

An error-correcting entity receiving an REJ command or response frame shall initiate sequential transmission 
(retransmission) of 1 frames starting with the I frame indicated by the N(R) contained in the REJ frame. 

An error-correcting entity receiving an SREJ command or response frame shall initiate retransmission of the I frame(s) 
indicated by the N(R) and, if present, the information field contained in the SREJ frame. 

An REJ or SREJ exception condition is cleared when the requested I frame is received or when an SABME or DISC 
command is received. 

Neither REJ or SREJ frames may be retransmitted [in case of loss of either, the expiration of timer T401 in the remote 
error-correcting entity will eventually cause resending of the requested I frame(s)]. However, if examination of received 
I frames indicates that retransmission of the requested frame has occurred without having satisfied the reject condition, a 
new REJ or SREJ condition may optionally be established and the REJ or SREJ frame repeated. 

8.5.2 N(R) sequence error 

An N(R) sequence error exception condition occurs in the transmitter when a valid supervisory frame or I frame is 
received that contains an invalid N(R) value. 

A valid N(R) is one that is in the range V(A) < N(R) < V(S). 
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The information field contained in an I frame that is correct in sequence and format may be delivered to the control 
function by means of the L-DATA indication primitive. 

The error-correcting entity shall initiate termination according to 8.4.9.2. 

8.5.3 Timer-recovery condition 

If an error-correcting entity, due to a transmission error, does not receive a single 1 frame or the last 1 frame(s) in a 
sequence of 1 frames, it will not detect an out-of-sequence exception condition and, therefore, will not transmit an REJ or 
SREJ frame. 

The error-correcting entity that transmitted the unacknowledged I frame(s) shall, on the expiry of timer T401, take 
appropriate recovery action as defined in 8.4.8 to determine at which 1 frame retransmission must begin. 

8.5.4 Invalid-frame condition 

Any frame received that is invalid (as defined in 8.13) shall be discarded, and no action shall be taken as a result of that 
frame. 

As an optional procedure in response to an invalid frame, an error-correcting entity may transmit an REJ frame rather 
than ignoring the frame without taking any action. In all other respects, the received frame shall be discarded, without 
any indication to the control function of its receipt. 

8.5.5 Frame-rejection condition 

A frame-rejection condition results from one of the conditions described in 8.2.4.1 (first paragraph) or 8.2.4.12, items b), 
c) and d). 

Upon occurrence of a frame-rejection condition while an error-corrected connection is established, the error-correcting 
entity shall initiate termination (see 8.4.9.2). At other times, the frame causing the condition shall be discarded. 

NOTE - For satisfactory operation, it is essential that a receiver is able to discriminate between invalid frames, as defined 
in 8.1.3, and 1 frames with an information field that exceeds the maximum established length [see item d) in 8.2.4.12]. An unbounded 
frame may be assumed and, thus, discarded if two times the longest-permissible frame plus two octets are received without a flag 
detection. 

8.5.6 Receipt of an FRMR response frame 

Upon receipt of an FRMR response frame in the connected state, the error-correcting entity shall initiate termination 
(see 8.4.9.2). 

8.5.7 Unsolicited response frames 

The action to be taken on the receipt of an unsolicited response frame is defined in Table 9. 

8.6 Transfer of user-control information 

User-control information is transferred using the information field of UI frames. A UI frame has the same value of DLCI 
as that used for transferring user data. 

In general, the transfer of user-control information can be done immediately or in sequence with respect to user data. In 
the first case, the UI frame shall be transmitted immediately after transmission of the current 1 frame, if any, is 
completed. In the second case, the UI frame is transmitted only after acknowledgement is received for all 
unacknowledged I frames. Whether subsequent transmission of 1 frames can resume immediately after the transmission 
of the UI frame or await some further event depends on the type of control information transmitted. 

See 8.13 for procedures for transmitting a break signal between V.24 interfaces. 

8.7 Orderly release of an error-corrected connection 
8.7.1 General 

These procedures shall be used to return to the disconnected state. 

The control function requests release of an error-corrected connection by use of the L-RELEASE request primitive. 
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TABLE 9/V.42 



Actions taken on receipt of unsolicited response frames 



Unsolicited response 
frame 


Disconnected 
state 


Awaiting 
connection 
establishment 


Awaiting 
connection 
release 


Connected state 


Not in timer- 

ictuvci y 

condition 


In timer-recovery 

IrUIIUlllUU 


UA response 
F= 1 


Ignore * 


(Solicited) 


(Solicited) 


Ignore * 


Ignore * 


UA response 
F = 0 


Ignore * 


Ignore * 


Ignore * 


Ignore * 


Ignore * 


DM response 
F= 1 


Ignore 


(Solicited) 


(Solicited) 


Ignore * 


(Solicited) 


DM response 
F = 0 


Establish 
connection 


Ignore 


Ignore 


Termination 
connection 


Termination 
connection 


RR, RNR, REJ 
response: F = 1 


Ignore 


Ignore 


Ignore 


Ignore * 


(Solicited) 


RR, RNR, REJ 
response: F = 0 


Ignore 


Ignore 


Ignore 


(Solicited) 


(Solicited) 


SREJ response 
F= 1 


Ignore 


Ignore 


Ignore 


Termination 
connection 


Termination 
connection 


SREJ response 
F = 0 


Ignore 


Ignore 


Ignore 


(Solicited) 


(Solicited) 


NOTES 

1 - For ignore-cases marked with an asterisk (*), the error-correcting entity shall inform the control function of a protocol 

violation. Receipt of a UI frame with an unrecognized encoding shall be signalled to the control function as a protocol 
violation. 

2 - Cases marked as (solicited) represent proper protocol operation. 



All frames other than unnumbered frames received during the release procedures shall be ignored. 

All outstanding L-DATA and L-S1GNAL request primitives and all associated frames in queue shall be discarded. 

8.7.2 Release procedure 

An error-correcting entity shall initiate a request for release of the connection by transmitting the disconnect (DISC) 
command. 

NOTE - To avoid misinterpretation of a received DM response frame, the DISC frame shall always be transmitted with its 
P bits set to 1. 

Timer T401 shall then be started and the retransmission counter reset. 

An error-correcting entity receiving a DISC command while in the connected state shall transmit a UA response with the 
F bit set to the same binary value as the P bit in the received DISC command. An L-RELEASE indication primitive shall 
be passed to the control function, and the disconnected state shall be entered. 

If the originator of the DISC command receives either: 

- a UA response with the F bit set to 1 ; or 

a DM response with the F bit set to 1 , indicating that the peer error-correcting entity is already in the 
disconnected state, 

it shall enter the disconnected state and stop timer T401 . 
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The error-correcting entity that issued the DISC command is now in the disconnected state and will notify its control 
function by means of the L-RELEASE indication primitive. The conditions relating to this state are defined in 8.8. 

8.7.3 Procedure on expiry of timer T401 

If timer T401 expires before a UA or DM response with its F bit set to 1 is received, the originator of the DISC 
command shall: 

- retransmit the DISC command as defined in 8.7.2; 
restart timer T40 1 ; and 

- increment the retransmission counter. 

If the error-correcting entity has not received the correct response as defined in 8.7.2, after N400 attempts to recover, the 
error-correcting entity shall enter the disconnected state and notify its control function by means of the L-RELEASE 
indication primitive. 

8.8 Disconnected state 

While in the disconnected state: 

the receipt of a DISC command shall result in the transmission of a DM response with F bit set to the 
value of the received P bit; 

- on receipt of an SABME command, the procedures defined in 8.3 shall be followed; 

on receipt of an unsolicited DM response with the F bit set to 0, the error-correcting entity shall, if it is 
able to and the control function is willing, initiate the error-connection establishment procedures by the 
transmission of an SABME (see 8.3.2.1); otherwise, the DM shall be ignored; and 

all other frame type shall be discarded. 

8.9 Collision of unnumbered commands and responses 

8.9.1 Identical transmitted and received set-mode commands 

If transmitted and received unnumbered set-mode commands (SABME or DISC) are the same, the error-correcting 
entities shall send the UA response at the earliest possible opportunity. The indicated state (the connected state if the 
commands were SABMEs, or the disconnected state if they were DISCs) shall be entered after receiving the UA 
response. The error-correcting entity shall notify its control function by means of the appropriate primitive. 

8.9.2 Different transmitted and received set-mode commands 

If the transmitted and received unnumbered set-mode commands (SABME or DISC) are different, the error-correcting 
entities shall issue a DM response at the earliest possible opportunity. Upon receipt of a DM response with the F bit set 
to 1, the error-correcting entity shall enter the disconnected state and notify its control function by means of an 
L-RELEASE indication primitive. 

8.9.3 Unsolicited DM response and SABME or DISC command 

A DM response with its F bit to 0 colliding with an SABME or DISC command shall be ignored. 

8.10 Negotiation/indication of parameter values and optional procedures 
8.10.1 General 

Upon receipt of an L-SETPARM request primitive from its control function, an error-correcting entity shall initiate 
procedures using XID frames to negotiate/indicate parameter values and optional procedures with the remote DCE. If 
data transfer is possible (i.e. the error-corrected connection is in the connected state), then the error-correcting entity 
shall first transmit an RNR command frame with its P bit set to 1 (see 8.4.7) to its peer and cease transmission of 
1 frames. 

NOTE - This is necessary since parameters/procedures to be negotiated/indicated may affect the procedures governing 
I frame transmission. 
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Upon completion of the negotiation/indication process, the affected parameter values/procedure settings shall be 
recorded. If a busy condition had been initiated as part of the process of changing parameter values/procedure settings 
(see above), then an indication of busy-condition clearance shall be transmitted. 

Clauses 9 and 10 indicate which parameters and procedures, respectively, may be negotiated/indicated while 12.2 
indicates the encoding of the information field of the XID frame. 

8.10.2 Negotiation/Indication procedure 

Upon receipt of an L-SETPARM request primitive, the error-correcting entity shall transmit an XID command frame. 
The information field of this frame shall be used to convey the parameters/procedures to be negotiated/indicated to the 
remote error-correcting entity. Timer T401 shall then be started and the retransmission counter, N400, reset. 

NOTE - When sending the above frame as the first protocol frame following the detection phase (if used) or establishment 
of the physical connection (if the detection phase is not used), the originator shall first transmit flag patterns for a period of time 
sufficient to guarantee the transmission of at least 16-flag patterns. 

On receipt of an XID command frame used for parameter/procedure negotiation/indication, the error control function 
shall issue an L-SETPARM indication primitive to its control function, passing it the contents of the information field. 

On receipt of an L-SETPARM response primitive from its control function, an error control function shall return the 
indicated parameter values/procedure settings in the information field of an XID response frame. 

If 32-bit FCS is requested and agreed during the protocol establishment phase (see 7.2.2), a called DCE shall be capable 
of checking subsequent frames against both the 16-bit FCS (see 8.1.1.6.1) and the 32-bit FCS (see 8.1.1.6.2) 
simultaneously (a frame shall be discarded only if it fails both FCS checks). Until a SABME frame is received, the called 
DCE transmits frames with a 16-bit FCS. Receipt of a SABME frame with 16- or 32-bit FCS indicates use of 
the corresponding FCS for all subsequent frames (and checking of frames against both the 16-bit and 32-bit FCS may be 
disabled). Receipt of another XID command frame, with a 16-bit FCS, shall be responded to according to the 
negotiation/indication rules using an XID response frame with a 16-bit FCS. 

On receipt of an XID response frame used for parameter/procedure negotiation/indication, the error control function 
shall inform its control function by an L-SETPARM confirmation primitive of the values contained in the information 
field. 

8.10.3 Procedure on expiry of timer T401 

If timer T401 expires before receipt of the XID response frame, the error-correcting entity shall: 
retransmit the XID command as above; 
restart ti mer T40 1 ; and 
increment the retransmission counter (N400). 

After retransmission of the XID command N400 times and failure to receive an XID response, the error-correcting entity 
shall notify the control function that the negotiation/indication procedure did not complete. 

The value of N400 is defined in 9.2.2. 



8.11 Loop-back test 

Upon receipt of an L-TEST request primitive from its control function, the error-correcting entity shall transmit a TEST 
command frame with its P bit set to 0. The information field of the TEST frame shall be used to convey the information 
provided by the control function. An L-TEST request primitive may be received at any time after completion of the 
protocol establishment phase. Its receipt does not affect the flow of other frames. 

On receipt of a TEST command frame with its P bit set to 0, the error-correcting entity shall issue an L-TEST indication 
primitive to its control function that also conveys the contents of the information field from the received TEST frame. 
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8.12 Monitoring functions 

8.12.1 General 

The procedural elements defined in the earlier parts of clause 8 allow for the supervision of the error-corrected 
connection. This subclause describes procedures that may be used to provide this supervision function. The use of this 
function is optional. 

8.12.2 Supervision during the connected state 

The connection verification is a service provided by the error-correcting entity to its control function. This implies that 
the control function is informed in case of a failure only. Furthermore, the procedure may be incorporated in the 
"normal" exchange of information and may become more efficient than a procedure based on the involvement of the 
control function. 

The procedure is based on supervisory command frames (RR command, RNR command) and timer T403, and operates 
during the connected state as follows. 

If there are no frames being exchanged on the error-corrected connection (neither new nor outstanding I frames, nor 
supervisory frames with a P bit set to 1), there is no means to detect a faulty error-corrected connection condition. Timer 
T403 represents the maximum time allowed without frames being exchanged. 

If timer T403 expires, a supervisory command with a P bit set to 1 is transmitted. Such a procedure is protected against 
transmission errors by making use of timer T401 and the N400 retransmission count. 

8.12.3 Connection verification procedures 

8.12.3.1 Start timer T403 

The timer T403 is started: 

when the connected state is entered; and 

in the connected state whenever timer T40 1 is stopped. 
Upon receiving an 1 or supervisory frame, timer T403 will be restarted if timer T401 is not to be started. 

8.12.3.2 Stop timer T403 

The timer T403 is stopped: 

when, in the connected state, the timer T401 is started; and 
upon leaving the connected state. 

8.12.3.3 Expiry of timer T403 

If timer T403 expires, the error-correcting entity will act as follows (it should be noted that timer T401 is neither running 
nor expired): 

a) set the retransmission count variable to 0; 

b) enter the timer-recovery condition (see 8.5.3); 

c) transmit a supervisory command with the P bit set to 1 as follows: 

if there is not an own-receiver busy condition, transmit an RR command; or 
if there is an own-receiver busy condition, transmit an RNR command; 

d) start timer T401; and 

e) inform the control function after N400 retransmissions. 
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8.13 Transfer of break 

8.13.1 General 

Upon receipt of an L-SIGNAL request primitive from its control function, an error-correcting entity shall transmit a Ul 
command frame with its P bit set to 0. The information field of the UI command frame shall be encoded to indicate a 
break (BRK) message and shall contain the break-handling option as indicated by the control function. If the L-SIGNAL 
request primitive includes a break length, it shall also be encoded in the information field of the UI frame. (See 12.3 on 
the encoding of UI frames for transferring a break signal.) Actions taken by the DCE (including the error-correcting 
entity) are specified in Table 4. 

On receipt of a UI command frame indicating a BRK, the error-correcting entity shall issue an L-SIGNAL indication 
primitive to its control function, conveying the break-handling option and, if present, the break length and follow the 
actions specified in Table 5. On receipt of an L-SIGNAL response primitive from its control function, an error- 
correcting entity shall transmit a Ul response frame as soon as possible with its F bit set to the same binary value as the 
received UI command frame. The information field of the Ul response frame shall be encoded to indicate a break 
acknowledgement (BRKACK) message. 

On receipt of a UI response frame with a BRKACK message in reply to a UI command frame conveying a BRK 
message, an error-correcting entity shall issue an L-SIGNAL confirmation primitive to its control function. 

NOTE - The exchange of Ul frames, in and of itself, does not provide a confirmed service. The confirmed nature of the 
L-SIGNAL service provided to the control function, as described here, comes about through the association and interpretation of the 
contents of the information fields of the UI frames exchanged and not the association of a UI response frame with a previously- 
transmitted UI command frame. 

8.13.2 State variables and parameters 

8.13.2.1 Send and receive sequence numbers 

To distinguish between unique and duplicate UI frames carrying break information, an error-correcting entity shall 
perform a sequencing operation, modulo 2, on the information field of the UI frame. Bit 8 of the first octet of the 
information field shall be used for this purpose. As such, bit 8 serves as a break send sequence number, N(SB), in BRK 
message while it serves as a break receive sequence number, N(RB), in BRKACK messages. 

8.13.2.2 Send state variable V(SB) 

The error-correcting entity shall maintain the break send state variable V(SB). V(SB) denotes the value of N(SB) in the 
next BRK message sent as a result of receiving an L-SIGNAL request primitive from the control function. V(SB) is 
complemented each time a transmitted BRK message is correctly acknowledged by a BRKACK message. Initially, when 
the physical connection has been established, V(SB) is set to zero. 

8.13.2.3 Receive state variable V(RB) 

The error-correcting entity shall maintain the break receive state variable V(RB). V(RB) denotes the expected value 
of N(SB) in the next BRK message to be received. If N(SB) in the next received BRK message is equal to V(RB), then 
V(RB) shall be complemented prior to sending the BRKACK message. Initially, when the physical connection has been 
established, V(RB) is set to zero. 

8.13.3 Break procedures 

8.13.3.1 Transmitting a BRK message 

On receipt of an L-SIGNAL request primitive, the error-correcting entity shall transmit a BRK message in a UI 
command frame with its P bit set to 0. The error-correcting entity shall set N(SB) to the current value of V(SB), start the 
acknowledgement timer T401 (see 9.2.1) and set the retransmission counter N400 (see 9.2.2) to zero. 
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8.133.2 Receiving a BRK message 

When receiving a BRK message in a Ul command frame, the error-correcting entity shall check whether N(SB) is equal 
to the current value of V(RB). If it is, the error-correcting entity shall issue an L-SIGNAL indication primitive to the 
control function, passing it the break-handling option and, if present, the length of break information. The error- 
correcting entity shall also complement the value of V(RB). 

Upon receipt of an L-SIGNAL response primitive, the error-correcting entity shall transmit a BRKACK message in a UI 
response frame with N(RB) equal to the value of V(RB). The F bit of the UI response frame shall be set to the same 
binary value as the received UI command frame. 

If N(SB) in the received BRK message is not equal to V(RB), then the error-correcting entity shall discard the 
BRK message and retransmit the previous BRKACK message with N(RB) equal to the current value of V(RB). No 
L-SIGNAL indication primitive shall be issued to the control function. 

8.13.3.3 Receiving a BRKACK message 

When receiving a BRKACK message in a Ul response frame, the error-correcting entity shall check whether N(RB) is 
equal to V(SB) + 1. If it is, the error-correcting entity shall complement V(SB), stop the acknowledgement timer T401, 
and issue an L-SIGNAL confirmation primitive to the control function. If N(RB) is not equal to V(SB) + 1, the error- 
correcting entity shall ignore the BRKACK message. 

8.13.3.4 Expiration of the acknowledgement timer 

If T401 expires before a BRKACK message is received to acknowledge the last BRK message transmitted, the error- 
correcting entity shall retransmit the BRK message with N(SB) equal to the current value of V(SB). No more than N400 
retransmissions shall occur. Failure to receive a BRKACK after N400 retransmissions shall be reported to the control 
function. 



9 System parameters 

This clause specifies the parameters needed for proper operation. For each parameter, it indicates: 

a) whether the parameter is used by the control function or the error control function; 

b) the definition of the parameter; 

c) whether information about the parameter is carried in XID frames and, if so, whether the information is 
for negotiation or indication purposes; 

d) for those parameters that are negotiated by XID frames, what the negotiation rules are; and 

e) what the default value of the parameter is. 

9.1 Parameters of the control function 
9.1.1 Detection phase timer (T400) 

The detection phase timer governs the amount of time that a control function in an originating or answering DCE waits 
for the ADP or the ODP, respectively (see 7.2.1). Information about this timer is not carried in XID frames. The default 
value shall be 750 ms. (This is the estimated maximum propagation delay of all required transmissions including a single 
satellite link, plus sufficient time for the required transmissions at the data rate used in any V-Series modem that uses 
asynchronous- to-synchronous conversion.) 

NOTE - Implementations may provide a mechanism for the user to set a value different from the default. 

9.2 Parameters of the error control function 
9.2.1 Acknowledgement timer (T401) 

The acknowledgement timer governs the amount of time that an error-correcting entity will wait for an 
acknowledgement before resorting to other action (e.g. transmitting a frame). Information about this timer is not carried 
in XID frames. The two error-correcting entities associated with an error-corrected connection may operate with a 
different value of T401. 
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NOTE - This timer should be regarded as a logical parameter. That is, there can be one acknowledgement timer associated 
with each LAPM function (e.g. transmitting an I frame, transmitting a BRK message) that requires an acknowledgement to be 
received before expiration of this timer. This does not necessarily imply separate timer circuits. 

Appendix IV shows the various factors that influence T401 . 

9.2.2 Maximum number of retransmissions (N400) 

N400 governs the maximum number of times that an error-correcting entity will re-attempt a procedure requiring a 
response. Information about this counter is not carried in XID frames. The two error-correcting entities associated with 
an error-corrected connection may operate with a different value of N400. While no default value is specified for N400, 
it shall have a minimum value of 1 . 

9.2.3 Maximum number of octets in an information field (N401) 

N401 governs the maximum number of octets that can be carried in the information field of an I frame, an SREJ frame, 
an XID frame, a UI frame, or a TEST frame transmitted by an error-correcting entity. The default value of N401 shall be 
128 octets for both directions of data transmission. If the default is not satisfactory to the negotiation initiator, then a 
different value may be negotiated separately for each direction by use of the XID frame. The initiator of the negotiation 
shall indicate the N401 value it wishes to use for each direction (absence of a value indicates use of the default). The 
responder to the negotiation indicates the N401 value it wishes to use for each direction. The value chosen by the 
responder shall be between the value chosen by the initiator and the default value, inclusive, and shall be the value used 
during the operation of the error-corrected connection (unless overridden by a subsequent negotiation). 

9.2.4 Window size (k) 

k governs the maximum number of I frames that an error-correcting entity can have outstanding (i.e. unacknowledged). 
The default value of k shall be 15 for both directions of data transmission. If the default is not satisfactory to the 
negotiation initiator, then a different value may be negotiated separately for each direction by use of the XID frame. The 
initiator of the negotiation shall indicate the k value it wishes to use for each direction (absence of a value indicates use 
of the default). The responder to the negotiation indicates the k value it wishes to use for each direction. The value 
chosen by the responder shall be between the value chosen by the initiator and the default value, inclusive, and shall be 
the value used during the operation of the error-corrected connection (unless overridden by a subsequent negotiation). 

9.2.5 Reply delay timer (T402) - Optional 

T402 is the maximum amount of time the error-correcting entity may wait, following receipt of any frame requiring a 
reply, before it initiates transmission of an appropriate reply in order to ensure that the reply frame is received by the 
remote error-correcting entity prior to expiration of the remote error-correcting entity's T401 timer. Information about 
this timer is not carried in XID frames. If this timer expires, then the reply that would have been returned prior to its 
expiration shall not be sent. 

NOTE - The necessity for an operation of such a timer remains for further study. 

9.2.6 Inactivity timer (T403) - Optional 

T403 represents the maximum amount of time an error-correcting entity will allow to elapse without frames being 
exchanged on the error-corrected connection. Information about this timer is not carried in XID frames. The two 
error-correcting entities associated with an error-corrected connection may operate with a different value of T403. While 
no default value is specified for T403, it should take on relatively small values so that faults can be detected early. 

9.2.7 DLCI values 

The DLCI value in the address field of a frame transmitted by the error control function serves to identify the connection 
between two peer error-correcting entities. Information about these values is not carried in XID frames. DLCI values are 
defined in Table 10. 
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TABLE 10/V.42 
Allocation of DLCI values 



DLCI value 


Used for 


0 


DTE-to-DTE (V.24 interfaces) data 


1-31 


Reserved for future use by this Recommendation 


32-62 


Not reserved for use by this Recommendation 


63 


Reserved for control-function to control -function information (for further study) 


NOTE -The DLCI assignments above are for use with an address field consisting of a single octet (see 8.2.1). Allocation of 
DLCI values that make use of optional octet 2A (see Figure 8) is for further study. 



9.3 Other parameters 

Other parameters for use in conjunction with this Recommendation are defined in Recommendation V.42 bis. 



10 Negotiation of optional procedures 

Within the scope of this Recommendation, there are four procedures that are optional for error control function 
operation. These are: 

a) selective retransmission, using an SREJ frame to request retransmission of only a single frame; 

b) loop-back test, where a control function can determine whether its peer is operational; and 

c) extended FCS, where a 32-bit FCS (rather than a 16-bit FCS) is used; 

d) selective retransmission, using an SREJ frame to request transmission of multiple frames with span list 
encoding. 

Furthermore, an optional data compression procedure, as defined in Recommendation V.42 bis, may be used in 
conjunction with the LAPM procedures. 

Use of any optional procedure requires agreement by both control functions using the mechanisms in 8.10. The 
negotiation-initiator can choose whether to request use of a particular procedure, the procedure is used only if the 
negotiation-initiator requests its use and the responder agrees to its use. 

For selective retransmission purposes, the negotiator-initiator may propose either or both of a) and d) options. The 
responder may choose not to use selective retransmission (i.e. use REJ); alternatively, if it wants to use selective 
retransmission, it shall choose only one of the options a) or d). 



11 Control function-to-control function connection 

An error-corrected connection, with a DLCI value of 63, has been reserved for use as a control function-to-control 
function connection. The protocol used between two control functions is for further study. 



12 Encoding of information fields 
12.1 Information fields in I frames 

The encoding of the information field of I frames is determined by the use of the error-corrected connection (e.g. when 
used to carry data received from the V.24 interface). 
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12.2 Information fields in XID frames 
12.2.1 General 

The general structure of the information field of an XID frame is based on the encoding in ISO Standard 8885, including 
Addendum 3, and is shown in Figure 1 1 below. The information field is composed of a number of subfields. These 
subfields are a format identifier subfield, zero or more data link layer subfields and, possibly, a user data subfield. 

When an octet encoding is shown for any of the subfields, it is shown with the right-most bit being the low-order bit and 
the bit transmitted first. 

12.2.1.1 Format identifier subfield 

Format Identifier (FI) subfield is one octet in length and is the first octet of the information field of the XID frame. In 
general, the FI is encoded such that it can designate 128 different formats standardized by ISO and 128 different formats 
defined by users. Each ISO-standardized format is associated with a different FI value. The only such format defined at 
this time is the "general purpose" format. 

12.2.1.2 Data link layer subfields 

Data link layer subfields are used to specify various data link layer characteristics, such as operational parameters. In 
terms of Figure 1 1, a data link layer subfield consists of a Group Identifier (GI) one octet in length, a Group Length 
(GL) two octets in length, and a parameter field (whose length is given by GL). The parameter field, in turn, is similarly 
decomposed into one or more sets of a Parameter Identifier (PI), a Parameter Length (PL), and a Parameter Value (PV) 
(the parameter length, however, is only one octet in length). 

The data link layer subfields, if present, follow in ascending order according to their GI values. 
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FIGURE ll/V.42 
General format of XID information field 



12.2.1.3 User data subfield 

A GI has been defined to specify a user data subfield used in conjunction with the "general purpose" FI. This subtle], 
which follows all data link layer subfields as Figure 1 1 shows, does not contain a GL. The subsequent information is 
bounded by the frame's FCS field. 

For the purposes of this Recommendation, this subfield is also divided into sets of Pis, PLs, and PVs. 
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12.2.2 Encoding for negotiation/indication of parameter values and optional procedures 

The information field shall be encoded as specified below. Fields that are not recognized are ignored. 
Format identifier subfield 

For negotiation/indication of parameter values and optional procedures, the FI subfield shall be encoded as "10000010" 
to indicate the ISO-standardized "general purpose" FI. 

Data link layer subfields 

Only two of the data link layer subfields specified in ISO 8885 shall be used in conjunction with this Recommendation. 
These are: 

a) the "parameter negotiation" subfield (this subfield has a GI value of "10000000"); and 

b) the "private parameter negotiation" subfield (this subfield has a GI value of "1 1 1 10000"). 
The length of these subfields (GL) is dependent on the actual information to be transmitted. 

Each item to be negotiated and/or indicated is identified by a PI. Table 1 1 shows each item, its PI value, and with which 
data link layer subfield it is associated. 

User data subfield 

The user data subfield may be present independently of whether negotiation and/or indication is performed. This 
subfield has a GI value of " 1 11 11 11 P. 

The only parameter within this subfield defined in this Recommendation at this time is a "manufacturer ID". 
This parameter shall be identified by a PI value of "11111111". The encoding of the associated PV subfield is 
manufacturer-specific. The high-order bit of the first octet of the PV field is used as follows: 

bit = 0: Manufacturer IDs not assigned by ITU-T; 

bit = 1 : ITU-T-assigned manufacturer IDs (the assignment of these identifiers is for further study). 
When receiving a manufacturer ID that is not recognized, the manufacturer ID field is ignored. 

12.3 Information fields in UI frames 

In the encodings below, bit 1 is the low-order bit and is transmitted first. 

The first octet of the information field of a UI frame shall be encoded to indicate the usage of the field, as given in 
Table 12. 

12.3.1 Encoding of BRK message 

The encoding of a BRK message is shown in Figure 12. Bit 8 of octet 1 is used as a sequence number, modulo 2 
(see 8.13.2.1). 

Break-handling option 

The break-handling option is encoded as "DS", where: 

the "D" bit (bit 8 of octet 2) shall indicate whether data previously accumulated but not yet delivered 
should be discarded: 

D = 0 indicates no discarding of data 

D = 1 indicates discarding of data 

the "S" bit (bit 7 of octet 2) shall indicate whether the break should be delivered in sequence: 

S = 0 indicates that the break shall be delivered in sequence with respect to data generated before the 
break 

S = 1 indicates that the break shall precede all data previously received but not yet delivered. 
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TABLE lla/V.42 



Parameter/procedures 
associated with the "parameter negotiation" subfield 



PI 


Parameter/procedure 


Units 


Decimal 


Binary 






3 


00000011 


HDLC optional functions 


(Note 1) 


5 


00000101 


Maximum length of information field (N401): transmit 
direction (Note 2) 


bits 
(Notes 3 y 4) 


6 


00000110 


Maximum length of information field (N401): receive 
direction (Note 2) 


bits 
(Notes 3 y 4) 


7 


00000111 


Window size (k): transmit direction (Note 2) 


frames 
(Note 4) 


8 


00001000 


Window size (k): receive direction (Note 2) 


frames 
(Note 4) 


NOTES 

1 - The length of this item is 4 octets (i.e. PL = 4). The bits in these octets constitute a 32-bit mask, each for a particular 

HDLC optional function. Bit 1 of this mask is the low-order bit of octet I and is transmitted first; bit 9 is the low-order 
bit of octet 2, etc. The bits corresponding to the optional procedures used within this Recommendation are as follows: 

- 3A Selective retransmission procedure (SREI frame) single I frame request 

- 14 Loop-back test procedure (TEST frame) 

- 17 Extended FCS procedure (32-bit FCS) 

- 24 Selective retransmission procedure (SREJ frame) multiple I frame request with span list capability. 

A bit position set to 1 indicates request/agreement to use the procedure. A bit position set to 0 indicates no request/no 
agreement to use the procedure. 

For conformance with the encoding rules in ISO Standard 8885, the transmitter of an XID command frame shall set 
bit positions 2, 4, 8, 9, 12 and 16 to 1 . The transmitter of an XID response frame shall also set these bit positions to 1, 
except bit position 16 shall be set to 0 if bit position 17 is set to 1. A receiver of these frames should ignore these bit 
positions. 

2 - Transmit and receive directions are relative to the negotiation-initiator and responder. Therefore, for example, the 

negotiation-initiator would use PI = 7 to request a window size to be used for the direction of transmission of data 
from it to the remote DCE. The negotiation-responder would use PI = 8 to respond to this, indicating the window size 
to use for the direction from the negotiation-initiator to the negotiation-responder. 

3 - N401 is expressed in octets. However, for negotiation purposes, units of "bits" shall be used. 

4 -Parameter values for these items shall be encoded in binary. Within an octet, the first bit transmitted shall be the 
lowest-order bit. Where multiple octets are needed to express a parameter value, the first octet transmitted shall 
contain the higher-order bits. 



m. 
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TABLE llb/V.42 

Parameter/procedures 
associated with the "private parameter negotiation" subfield 



PI 




Parameter 


Note(s) 


Decimal 


Binary 


PL 






0 


00000000 


3 


Parameter set identification 


2 


1 


00000001 


1 


V.42 bis: Data compression request (P0) 


3 


2 


00000010 


2 


V.42 bis: Number of codewords (PI) 


1,3 


3 


00000011 


1 


V.42 bis: Maximum string length (P2) 


1,3 



NOTES 

1 - Parameter values for these items shall be encoded in binary. Within an octet, the first bit transmitted shall be the lowest-order 

bit. Where multiple octets are needed to express a parameter value, the first octet transmitted shall contain the higher-order 
bits. 

2 - This parameter shall always be the first parameter present in the "private parameter negotiation" subfield. Its PV value shall 

be the octets "00101010", "001 10100", "001 10010" (for "V.42"). 

3 - Parameters P0, PI and P2 operate together to specify whether data compression will be used and, if so, to specify the 

parameters associated with the procedure. During the protocol establishment phase, the presence of P0 shall indicate a request 
for data compression for the direction(s) indicated. Following the protocol establishment phase, absence of a parameter shall 
indicate that its previously negotiated value shall remain unchanged. 

For P0, its PV value indicates the direction for which data compression is requested; PV is encoded as "OOOOOOnn" where nn 
indicates: 

- 00: compression in neither direction (default) 

- 01: negotiation initiator-responder direction only 

- 10: negotiation responder- initiator direction only 

- 11: both directions 

4 - The value of PL (i.e. the length of the PV field), where not explicitly stated, shall be the smallest number of octets needed to 

express the value of the parameter. 



TABLE 12/V.42 
Encoding of octet 1 of the information field in a UI frame 



Message type 


Bits 

8 7 6 5 4 3 2 1 


BRK 

BRKACK 


XI 0 0 0 0 0 0 
XI 1 0 0 0 0 0 


NOTES 

1 - Encodings not shown in the table are reserved. 

2 - The value of X is set as discussed below. 
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Break length 

The break length, which is optional, is binary-encoded in octet 3 in units of 10 ms where bit 1 is the low-order bit. The 
value of "1 1 1 1 1 1 11" shall be used to indicate a break longer than 2.54 seconds. Absence of a break length field, or a 
value of zero in the break length field, in a received BRK message shall be interpreted as a break of default length. 
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FIGURE 12/V.42 
Format of UI information field for break 



12.3.2 Encoding of BRKACK message 

A BRKACK message contains only one octet. Bit 8 of octet 1 is used as a sequence number, modulo 2 (see 8.13.2.1). 

12.4 Information fields in TEST frame 

The information field in a TEST frame is used by the control function as part of a loop-back test. While specification of 
a particular encoding of this field is outside the scope of this Recommendation, the control function should ensure that 
the field is unique so that it can determine when a test has completed successfully. 

12.5 Information fields in SREJ frames 

When the optional m-SREJ procedure is used, the SREJ frame may contain an information field. In this case, the 
information field is encoded as given in 8.2.4.8.2 and Figure 9. 



Annex A 

Operation of the error control function - Alternative procedure 



A.l General 

This Annex specifies the frame structure and procedures for the proper operation of the alternative error-correcting 
procedure for DCEs. 



A.2 Format conventions 

See 8.1.2. 
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A.3 Start-stop, octet-oriented framing mode 

In this mode the error-correcting entities operate on an octet data stream. The framing format for start-stop, 
octet-oriented framing mode is shown in Figure A.l. This framing mode requires the use of four special octet values 
(SYN, DLE, STX, and ETX) for transparency. The transparency method is described in A.3.4 below. 

Each octet is transmitted with a start and stop bit. 
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Octet 1 
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Frame format for start-stop, octet-oriented mode 



A.3.1 Start-flag field 

All frames shall begin with the three-octet, start-flag sequence SYN-DLE-STX. The values for the flag sequence are 
shown in Figure A.l. 

A.3.2 Header field 

The contents of the header field are described in A.6.2 and A.6.3. 
A.3.3 Information field 

The information field of a frame, when present, contains transparent user data. 
A.3.4 Transparency 

The transmitting error-correcting entity shall examine the frame body (consisting of the header and information fields) 
and insert a DLE octet immediately following any occurrence of a DLE octet in the frame body octet stream. The 
receiving error-correcting entity shall examine the frame body and discard the second DLE of a two-octet 
DLE-DLE sequence. The first DLE is considered part of the frame body field. The DLE used in the start and end flag to 
delimit the STX and ETX control octets shall not be doubled, so that they shall be recognized as framing fields. 
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A.3.5 End-flag field 

All frames shall end with the two-octet, end-flag sequence DLE-ETX (followed by the FCS field). The values for the 
flag sequence are shown in Figure A.l . 

A.3.6 Frame Check Sequence (FCS) field 

The FCS is a 16-bit sequence generated by the Cyclic Redundancy Check (CRC) polynomial jc 16 + jc 15 + x 2 + 1. The 
frame body and ETX octet of the stop flag are included in the FCS calculation. The start flag and all DLE octets used to 
maintain data transparency (see A.3.4) are excluded from the FCS calculation. 

NOTE - The CRC polynomial used in this frame mode differs from that specified in 8. 1 . 1 .6. 1 . 
A.4 Bit-oriented framing mode 

In this mode, the error-correcting entities operate on a bit data stream. The framing format for bit-oriented mode is 
shown in Figure A.2. 
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FIGURE A.2/V.42 
Frame format for bit-oriented mode 



A.4.1 Flag sequence and transparency 

See 8.1.1.2. 

A A2 Header field 

The contents of the header field are defined in A.6.2 and A.6.3. 
A.4.3 Information field 

The information field of a frame, when present, contains transparent user data. The contents of the information field 
shall consist of an integer number of octets. 

A.4.4 Frame Check Sequence (FCS) field 
See 8.1.1.6.1. 

A.5 Invalid frames 

For octet-oriented framing mode, see 8. 1 .3, item d). For bit-oriented framing mode, see 8. 1 .3, items a) to d). 

f t 
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A.6 Alternative elements of procedure and field formats 
A.6.1 General 

The elements of procedure define the message formats that are used on an alternative error-corrected connection. 
A.6.2 Header field - Format 

The header field consists of fixed-length and variable-length parameters. Fixed-length parameters, or fixed parameters, 
have a predetermined length defined by the value of the type indication. Variable-length parameters, or vanable 
parameters, have a length of three or more octets. 

All valid header fields shall have a length indication (fixed parameter 0) and a type indication (fixed parameter 1) to 
identify the encoding for the remaining portion of the header field. The format is illustrated in Figure A.3. 

A.6.2.1 Fixed parameter 0 - Length indication 

The length indication shall be the first octet of the header field. The value of the length indication determines the total 
length of the header field, in octets. This length value does not include the length indication itself. 

The value of 255 shall be used to indicate that the next two octets constitute a 16-bit extended length indication. The 
length indication requires three octets to represent lengths over 254 octets. 

A.6.2.2 Fixed parameter 1 - Type indication 

The type indication shall be the second octet of the header field. The type indication identifies the header-field type and 
encoding for the remainder of the header field. The header-field types are shown in Table A.l . 

A.6.2.3 Fixed parameters 2 through n 

The presence of fixed parameters 2 through n is dependent on the header-field type. 

A.6.2.4 Variable parameters 

All variable parameters shall have three parts: 

a) parameter-type indication; 

b) parameter-length indication; 

c) parameter values. 

The structure of a variable parameter is shown in Figure A.4. 
A.6.2.4.1 Variable parameter type indication 

The variable parameter-type indication shall consist of one octet, containing a value in the range from 1 to 254. For each 
header-field type, there is a separate and independent numbering sequence for vanable parameter types. 

A.6.2.4.2 Variable parameter length indication 

The variable parameter-length indication shall be a single octet which specifies the number of octets contained in the 
variable parameter value. 

A.6.2.4.3 Variable parameter value 

The variable parameter field shall consist of one or more octets; the number of octets is specified by the parameter length 
indication. 

A.6.3 Header field - Parameters 
A.6.3.1 Modulus 

Each LT frame and LN frame is sequentially numbered and may have the value 0 through modulus minus 1 (where 
modulus is the modulus of the sequence numbers). The modulus is 256 and the sequence numbers cycle through the 
entire range. 
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Fixed parameter 0 
Length indication 
8 bits 



Fixed parameter 1 
Type indication 
8 bits 



Fixed parameter n 
(type-indication dependent) 



Octet 1 

2 
3 



Variable parameter 1 
(optional) 



Variable parameter 2 
(optional) 



Variable parameter n 
(optional) 



FIGURE A.3/V.42 
Header-field format 



TABLE A.1/V.42 
Header-field types 



Type indication 


Value 


Link request 




LR 


1 


Link disconnect 




LD 


2 


Link transfer 




LT 


4 


Link acknowledgement 




LA 


5 


Link attention 




LN 


6 


Link attention acknowledgement 


LNA 


7 



A.6.3.2 Send state variable V(S) 

The send state variable V(S) denotes the sequence number of the next in- sequence LT frame to be transmitted. V(S) can 
take on the values 0 through modulus minus I. The value of V(S) is incremented by 1 with each successive LT frame 
transmission, but cannot exceed N(R) of the last received LA frame by more than the maximum number of outstanding 
LT frames (k). The value of k is defined in A.6.4.1.6 and A.7.5.7. 

Upon data phase initialization, V(S) is set to 1. 
A.6.3.3 Send sequence number N(S) 

Only LT frames contain N(S), the send sequence number of transmitted LT frames. At the time that an in-sequence 
LT frame is designated for transmission, the value of N(S) is set equal to the value of the send state variable V(S). 
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Type indicator 



Length indication 
L 



Value 1 



Octet n + 1 
n + 2 

n + 3 



Value L 



n + 2 + L 



FIGURE A.4/V.42 
Variable parameter format 



A.6.3.4 Receive state variable V(R) 

The receive state variable V(R) denotes the sequence number of the next in-sequence LT frame expected to be received. 
V(R) can take on the values 0 through modulus minus 1. The value of V(R) is incremented by 1 by the receipt of an 
error-free, in-sequence LT frame whose send sequence number N(S) equals the receive state variable V(R). 

Upon data phase initialization, V(R) is set to 1. 

A.6.3.5 Receive sequence number N(R) 

All LA frames contain N(R), the send sequence number of the last received LT frame. At the time that an LA frame is 
designated for transmission, the value of N(R) is set equal to the current value of the receive state variable V(R) - 1. 
N(R) indicates that the error-correcting entity transmitting the N(R) has received correctly all LT frames numbered up to 
and including N(R). 

A.6.3.6 Attention send state variable V(SA) 

The attention send state variable V(SA) denotes the sequence number of the next in-sequence LN frame to be 
transmitted. V(SA) can take on the values 0 through modulus minus 1. The value of V(SA) is incremented by 1 with 
each successive transmission of an LN frame. 

Upon data phase initialization, V(SA) is set to 1 . 
A.6.3.7 Attention send sequence number N(SA) 

Only LN frames contain N(SA), the attention send sequence number of transmitted LN frames. At the time that an 
in-sequence LN frame is designated for transmission, the value of N(SA) is set equal to the value of the attention send 
state variable V(SA). . 

A.6.3.8 Attention receive state variable V(RA) 

The attention receive state variable V(RA) denotes the sequence number of the next in-sequence LN frame expected to 
be received. V(RA) can take on the values 0 through modulus minus 1. The value of V(RA) is incremented by 1 by the 
receipt of an error-free, in-sequence LN frame whose attention send sequence number N(SA) equals the attention receive 
state variable V(RA). 

Upon data phase initialization, V(RA) is set to 1 . 
A.6.3.9 Attention receive sequence number N(RA) 

The LN A frame contains N(RA), the attention send sequence number of the last received LN frame. At the time that an 
LNA frame is designated for transmission, the value of N(RA) is set equal to the current value of the receive state 
variable V(RA) - 1. N(RA) indicates that the error-correcting entity transmitting the N(RA) has received correctly all 
LN frames numbered up to and including N(RA). 
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A.6.3.10 Receive credit state variable R(k) 

The receive credit state variable R(k) denotes the number of LT frames the receiver is able to receive. The number of 
received LT frames not acknowledged plus R(/c) cannot be greater than k (the maximum number of outstanding 
LT frames). System parameter k is defined in A.7.5.7. 

When the error-correcting entity enters the data phase, R(k) is set equal to k. During the data phase, R(k) is updated by 
the error-correcting entity as often as is required to accurately represent the receiver's ability to accept LT frames. 

A.6.3.11 Receive credit number N(k) 

Only LA frames contain N(fc). At the time that an LA frame is designated for transmission, the value of N(k) is set equal 
to the value of the receive credit state variable R(k). N(k) indicates that the error-correcting entity transmitting the N(k) 
can properly receive LT frames numbered up to and including N(R) + N(k). 

A. 6.3. 12 Send credit state variable S(k) 

The send credit state variable S(k) denotes the number of LT frames the sender is able to transmit without receiving 
additional credit from the receiver. The number of LT frames not acknowledged plus S(k) cannot be greater than k (the 
maximum number of outstanding LT frames). System parameter/: is defined in A.7.5.7. 

Upon data phase initialization, S(/c) is set to k. 
A.6.4 Protocol establishment phase 

The alternative error-correcting procedure begins operation in the protocol establishment phase. In this phase, the error- 
correcting entity attempts to initialize an error-corrected connection for exchanging data. 

The protocol messages in the connection establishment message exchange shall be transmitted in start-stop, 
octet-oriented mode. The framing mode for the subsequent phases of error-corrected connection operation is determined 
during the protocol establishment phase. 

A.6.4.1 Link request (LR) frame 

The link request (LR) frame is used to establish an error-corrected connection between two error-correcting entities with 
an active physical connection. The LR frame is also used to negotiate operational parameters to be in effect for the 
duration of the error-corrected connection (see A.7.1 .5). 

The header-field parameters of the LR frame are shown in Table A.2. No information field is permitted with the 
LR frame. 

A.6.4.1.1 Fixed parameter 0 - Length indication 

The value of the length indication shall be a computed value equal to the length of the header field, excluding the length 
indicator. 

A.6.4.1.2 Fixed parameter 1 - Type indication 

The value of the type indication shall be an octet value of 1 . 
A.6.4.1.3 Fixed parameter 2 - Constant parameter 1 

This constant parameter shall be the third octet of the header field. The value of this constant is an octet value of 2. 

A.6.4.1.4 Variable parameter 1 - Constant parameter 2 

This constant parameter shall be an octet sequence of value (1,6,1,0,0,0,0,255). 

A.6.4.1.5 Variable parameter 2 - Framing mode parameter 

The framing mode parameter defines the framing mode to be used on the error-corrected connection. 
Two-way simultaneous, start-stop, octet-oriented framing mode shall be represented by framing mode 2. 
Two-way simultaneous, bit-oriented framing mode shall be represented by framing mode 3. 
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TABLE A.2/V.42 
Link request header-field parameters 



Parameter name 


F 

V 


M 
0 


Value name 


Value 


Length indication 


F 


M 




Variable 


Type indication 


F 


M 


LR 


1 


f** nncMnt norimPtPf 1 

v_ui]Mdiii pdrdiiicici i 


F 


M 




2 


Constant parameter 2 


V 


M 


Type 
Length 

- 


1 

6 
1 

0 
0 
0 
0 

255 


Framing mode 


V 


M 


Type 
Length 
Mode 

(see A. 


2 
1 

2 or 3 

6.4.1.5) 


Maximum number of 
outstanding LT frames, k 


V 


M 


Type 
Length 
k 


3 
1 

Variable 


Maximum information field 
length, N401 


v 

V 


M 


Tvnp 
Length 
Max length 
(two octets) 


4 

2 

Variable 


Data phase optimization 


V 


M 


Type 
Length 
Facilities 

(see A 


8 
1 

Variable 

6.4.1.8) 


F Fixed parameter 
M Mandatory parameter 
V Variable parameter 
O Optional parameter 



An error-correcting entity that supports framing mode 3 must also support framing mode 2. 

The responding error-correcting entity sends a response LR with the framing mode parameter set to the lesser of the 
framing-mode values for the framing mode that is supported by the responding entity or the framing mode parameter 
value received in the initiating LR frame. The framing mode represented by the framing mode parameter value in the 
response LR determines the framing mode used on the error-corrected connection after the protocol establishment phase 
is completed. 

A.6.4.1.6 Variable parameter 3 - Maximum number of outstanding LT frames parameter, k 

The maximum number of outstanding LT frames parameter, k, defines the maximum number of LT frames with 
maximum-length information fields that an error-correcting entity may send at a given time without waiting for an 
acknowledgement. The value of k shall never exceed the sequence number modulus minus 1 . . 

Any value of k less than or equal to the maximum value may be used. 
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A.6.4.1.7 Variable parameter 4 - Maximum information field length parameter N401 

The maximum information- field length parameter, N401, defines the maximum length of user data, in octets, that can be 
sent in the information field of the link transfer (LT) frame. 

A. 6.4.1.8 Variable parameter 8 - Data phase optimization 

The data phase optimization parameter defines optional facilities that may be supported on an error-corrected connection 
to improve data throughput. 

The value of this parameter is a bit map that indicates protocol facilities to be used, as follows: 

bit 1 1 = maximum information-field length of 256 octets; 

bit 2 1 = fixed field LT and LA frames; 

bit 3-8 reserved. 
Reserved bits are set to 0 on transmission and ignored upon receipt. 

The responding error-correcting entity sends a response LR with a data phase optimization parameter if it agrees to use 
any data phase optimization facility. The facilities represented by the bit values in the response LR determine the 
facilities to be used on the error-corrected connection during the data phase. 

A.6.4.2 Link acknowledgement (LA) frame 

The link acknowledgement (LA) frame is used to confirm the completion of the protocol establishment phase of the 
alternative error-correcting procedure. The confirming LA is sent by the error-correcting entity that sent the initiating LR 
frame. 

Upon sending or receiving the confirming LA of the connection-establishment, three-message exchange, the 
error-correcting entity enters the data phase. 

The header-field parameters of the link acknowledgement frame are shown in Tables A.3a and A.3b. No information 
field is permitted in the LA frame. If the LR frame received from the responder indicates that fixed field LT and 
LA frames are to be used during the data phase (bit 2 of variable parameter 8 set to 1), the LA header format specified in 
Table A.3b shall be used; otherwise, the format specified in Table A.3a is used. 



TABLE A.3a/V.42 



Link acknowledgement header-field parameters 
(non-optimized data phase) 



Parameter name 


F 

V 


M 
O 


Value name 


Value 


Length indication 


F 


M 




7 


Type indication 


F 


M 


LA 


5 


Receive sequence number, 
N(R) 


V 


M 


Type 
Length 
N(R) 


1 
1 

8 bits 


Receive credit number, N{k) 


V 


M 


Type 
Length 
Credit 


2 
1 

8 bits 



A.6.4.2. 1 Fixed parameter 0 - Length indication 

The value of the length indication shall be an octet value of 7 in a non-optimized data phase (see Table A.3a) and 3 in an 
optimized data phase (see Table A. 3b). 
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TABLE A.3b/V.42 

Link acknowledgement header-field parameters 
(optimized data phase) 



Parameter name 


F 
V 


M 
0 


Value name 


Value 


Length indication 


F 


M 




3 


Type indication 


F 


M 


LA 


5 


Receive sequence number, 
N(R) 


F 


M 


N(R) 


8 bits 


Receive credit number, N(*) 


F 


M 


N(*) 


8 bits 



A.6.4.2.2 Fixed parameter 1 - Type indication 

The value of the type indication shall be an octet value of 5. 

A.6.4.2.3 Variable parameter 1 - Receive sequence number (non-optimized data phase) 

The receive sequence number parameter contains the value of the receive number, N(R), of the last correctly received 
LT frame. The value used for the receive sequence number in the protocol establishment phase confirming the LA shall 
be 0. 

A.6.4.2.4 Variable parameter 2 - Receive credit number (non-optimized data phase) 

The receive credit number parameter contains the value of the maximum number of LT frames that can be sent by an 
error-correcting entity before it must suspend sending LT frames and wait for an acknowledgement. 

The value used for the receive credit for the confirming LA is the value received as the receive credit in the response LR. 
A.6.4.2.5 Fixed format for variable parameters 1 and 2 (optimized data phase) 

When the fixed format LA frame facility is in effect during an optimized data phase, the receive sequence number and 
the receive credit number are included in the fixed part of the frame header field. 

The received sequence number value octet is fixed parameter 2. 

The received credit number value octet is fixed parameter 3. 

The header-field parameter of the LA frame in an optimized data phase is shown in Table A.3b. 
A.6.5 Disconnect phase 

The alternative error-correcting procedure terminates operation in the disconnect phase. The disconnect phase may be 
entered from any other phase of error-corrected connection operation. The disconnect phase shall use the same framing 
mode as used in the phase prior to the disconnect phase. 

A.6.5.1 Link disconnect (LD) frame 

The link disconnect (LD) frame is used to terminate operation of an active error-corrected connection, or to reject an 
attempt to establish an error-corrected connection. 

The header-field parameters of the LD frame are shown in Table A.4. No information field is permitted in the LD frame. 
A.6.5.1.1 Fixed parameter 0 - Length indication 

The value of the length indication shall be an octet value of 4 for LD frames without variable parameter 2 and 7 for 
LD frames with variable parameter 2. 
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TABLE A.4/V.42 
Link disconnect header-field parameters 



Parameter name 


F 
V 


M 
0 


Value name 


Value 


Length indication 


F 


M 


( spp A 

\ jv\» n.i 


4 or 7 

5.5.1.1) 


Type indication 


F 


M 


LD 


2 


Kcuson coue 


v 


M 


Tvr>e 
Length 
Value 

(see A. 


1 
1 

Variable 

6.5.1.3) 


User code 


V 


0 


Type 
Length 
Value 


2 
1 

Variable 



A.6.5.1.2 Fixed parameter 1 - Type indication 

The value of the type indication shall be an octet value of 2. 
A.6.5.1.3 Variable parameter 1 - Reason code 

The reason-code parameter defines the reason for disconnection when sent in an LD frame on an active error-corrected 
connection, or the reason for failure to establish when sent in an LD frame in response to a connection attempt. 

The reason codes are listed in Table A.5. Reason codes 1, 2 and 3 are used if the disconnect phase is the result of a 
failure in the protocol establishment phase. 





TABLE A.5/V.42 




Link disconnect reason code 


Code 


Reason 


1 


Protocol establishment phase error, LR expected but not 
received 


2 


LR constant parameter 1 contains an unexpected value 


3 


LR received with incompatible or unknown parameter value 


4-254 


Reserved 


255 


User- initiated disconnect 


NOTE - Code 3 is only used during the protocol establishment phase by the 
establishment initiator. 



A.6.5.1.4 Variable parameter 2 - User code 

The user code parameter is an optional parameter. If this parameter is present, this parameter defines the error-correcting 
user's reason for releasing the connection. 
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A.6.6 Data transfer phase 

The alternative error-correcting procedure transfers user data in the data transfer phase. 
A.6.6.1 Link transfer (LT) frame 

The function of the LT transfer (LT) frame is to transfer user data across the error-corrected connection in sequentially 
numbered information fields. The header-field parameters of the link transfer frame are shown in Tables A.6a and A.6b. 
The information field shall contain one or more octets of user data up to the maximum information-field length 
negotiated during the protocol establishment phase. A null (zero octets) information field is not allowed. 

A.6.6.1.1 Fixed parameter 0 - Length indication 

The value of the length indication shall be an octet value of 4 in a non-optimized data phase (see Table A.6a) and 2 in an 
optimized data phase (see Table A.6b). 



TABLE A.6a/V.42 

Link transfer header-field parameters 
(non-optimized data phase) 



Parameter name 


F 
V 


M 
0 


Value name 


Value 


Length indication 


F 


M 




4 


Type indication 


F 


M 


LT 


4 


Send sequence number, N(S) 


V 


M 


Type 
Length 
N(S) 


1 
1 

8 bits 



TABLE A.6b/V.42 

Link transfer header-field parameters 
(optimized data phase) 



Parameter name 


F 
V 


M 
0 


Value name 


Value 


Length indication 


F 


M 




2 


Type indication 


F 


M 


LT 


4 


Send sequence number, N(S) 


F 


M 


N(S) 


8 bits 



A.6.6.1.2 Fixed parameter 1 - Type indication 

The value of the type indication shall be an octet value of 4. 

A.6.6.1.3 Variable parameter 1 - Send sequence number parameter (non-optimized data phase) 

The send sequence number parameter defines the order of this frame and its information field in the data-sequence 
space. At the time that an LT frame is designated for transmission, the value of this parameter is set equal to the send 
state variable V(S). The send state variable is initially 1, and is incremented modulo 256 with each successive LT frame 
transmission. 
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A. 6.6.1. 4 Fixed format for variable parameter 1 (optimized data phase) 

When the fixed format LT frame facility is in effect during an optimized data phase, the send sequence number is 
included in the fixed part of the frame header field. 

The send sequence number value octet is fixed parameter 2. 

This format is shown in Table A.6b. 

A.6.6.2 Link acknowledgement (LA) frame 

The link acknowledgement (LA) frame is used to confirm the receipt of LT frames up to and including N(R). A single 
LA frame may acknowledge multiple LT frames. 

A.6.6.2.1 Header-field parameters 

The header-field parameters of the LA frame are shown in Tables A. 3a and A.3b; the parameters are described 
in A.6.4.2.1 through A.6.4.2.5. No information field is permitted in the LA frame. 

A.6.6.2.2 LT frame credit 

The LT frame credit parameter contains the value that represents the number of LT frames with maximum-length 
information fields that the receiver is able to accept at the moment of LA frame transmission. A credit value of zero 
serves to halt the transmission of LT frames by the sender. Transmission of LT frames from the sender shall resume 
when an LA frame with a non-zero credit value is sent. 

A.6.7 Transfer of break 

The attention frame provides a reliable mechanism for signalling between error-correcting entities a break condition on 
the DTE/DCE interface. 

A.6.7. 1 Link attention (LN) frame 

The header-field parameters of the link attention (LN) frame are shown in Table A.7. No information field is permitted 
in the LN frame. 



TABLE A.7/V.42 



Link attention header-field parameters 



Parameter name 


F 
V 


M 
O 


Value name 


Value 


Length indication 


F 


M 




7 


Type indication 


F 


M 


LN 


6 


Attention send sequence 
number, N(SA) 


V 


M 


Type 
Length 
N(SA) 


1 
1 

8 bits 


Attention type 


V 


M 


Type 
Length 
Break 


2 
1 

1 = D and E 
2 = non-D and E 
3 = non-D and non-E 


F Fixed parameter 
M Mandatory parameter 
V Variable parameter 
O Optional parameter 
D Destructive break 
E Expedited break 
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A.6.7.L1 Fixed parameter 0 - Length indication 

The value of the length indication shall be an octet value of 7. 

A.6.7.1.2 Fixed parameter 1 - Type indication 

The value of the type indication shall be an octet value of 6. 

A.6.7.1.3 Variable parameter 1 - Attention send sequence number 

The attention send sequence number, N(SA), parameter defines the order of this frame in the attention sequence space. 
At the time that an LN frame is designated for transmission, the value of this parameter is set equal to the attention send 
state variable V(SA). The attention send state variable is initially 1, and is incremented modulo 256 with each successive 
LN frame transmission. 

A.6.7.1 .4 Variable parameter 2 - Attention type 

The attention type parameter defines error-correcting entity handling of the break condition relative to the user data. 

If destructive break handling is specified, the error-correcting entity shall flush all data transmitted or received before the 
break signal that is in transit to the correspondent entity or not delivered to the user. 

If expedited break handling is specified, the error-correcting entity shall process the break signal immediately and ahead 
of any user data pending transmission. 

See 7.4 and 7.5. 

A.6.7.2 Link attention acknowledgement (LNA) frame 

The link attention acknowledgement (LNA) frame is used to acknowledge successful receipt of an LN frame. The 
header-field parameters of the LNA frame are shown in Table A.8. No information field is permitted in the LNA frame. 



TABLE A.8/V.42 

Link attention acknowledgement 
header-field parameters 



Parameter name 


F 
V 


M 
0 


Value name 


Value 


Length indication 


F 


M 




4 


Type indication 


F 


M 


LNA 


7 


Attention receive sequence number, 
N(RA) 


V 


M 


Type 
Length 
N(RA) 


1 
1 

8 bits 



A.6.7.2.1 Fixed parameter 0 - Length indication 

The value of the length indication shall be an octet of value 4. 

A.6.7.2.2 Fixed parameter 1 - Type indication 

The value of the type indication shall be an octet of value 7. 

A.6.7.2.3 Variable parameter 1 - Attention receive sequence number 

The attention receive sequence number parameter is used to acknowledge the receipt of LN frames up to and 
including N(RA). 
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A.7 Description of the error-correcting procedure 



A.7.1 Protocol establishment phase procedures 
A.7.1.1 Initiating the establishment procedure 

The protocol establishment phase begins after a physical connection is established. The originating DCE's 
error-correcting entity (the initiator) begins the procedures of the protocol establishment phase. The answering DCE's 
error-correcting entity (the responder) shall be ready to respond to protocol messages immediately after the physical 
connection is established. 

A.7.1.2 Initiator procedure 

The initiator shall begin connection establishment by transmitting an LR frame to the responder entity and starting its 
timer T401 in order to determine when too much time has elapsed waiting for a reply. When a reply LR is received, the 
initiator performs parameter negotiation (see A.7. 1.5) to determine the parameter values which will characterize the 
error-corrected connection. 

If negotiation is successful, the initiator transmits an LA frame and enters the data phase. 

The initiator shall resend the initial LR if: 

a) timer T401 expires while waiting for the LR response; or 

b) a protocol message arrives with an incorrect frame check sequence. 

After resending the initial LR, the initiator restarts its timer T401 and waits for a reply. If the timer T401 again expires or 
another protocol message arrives with an invalid frame check sequence, the initiator may reject the connection 
establishment. However, the initiator may also repeat this procedure. 

A.7.1. 3 Responder procedure 

The responder shall begin a connection establishment attempt by starting timer T401. When an LR is received, the 
responder performs parameter negotiation (see A.7. 1.5) to determine the parameter values which will characterize the 
error-corrected connection. 

If negotiation is successful, the responder transmits an LR to the initiator and starts its timer T401 in order to determine 
when too much time has elapsed waiting for an acknowledgement. When an acknowledgement LA is received, the 
responder enters the data phase. 

The responder shall resend the response LR if: 

a) timer T401 expires while waiting for the LA response; 

b) a protocol message arrives with an incorrect frame check sequence; or 

c) another LR arrives. 

After resending the response LR, the responder restarts timer T401 and waits for a reply. If the timer T401 again expires 
or if another protocol message arrives with an invalid frame check sequence, the responder rejects the connection 
establishment. 

A.7.1.4 Establishment rejection 

If the responder: 

a) receives an LR with parameters that the responder is not prepared to accept; or 

b) does not receive an expected reply, 
then the responder shall enter the disconnect phase. 
If the initiator: 

a) receives an LR with parameters that fail the parameter negotiation; or 

b) does not receive an expected reply, 
then the initiator shall enter the disconnect phase. 



Recommendation V.42 (10/96) 61 



A.7.1.5 Parameter neg tiation 

The error-correcting entity examines the parameters and parameter values of the LR it receives and compares them to its 
SernTpSmeters The negotiation ru.es are used to resolve parameter differences. If the negotiate rules cannot 
resolve the parameter differences, then negotiation fails. 

A.7.1-5.1 Constant parameter 1 

Fixed parameter 1 shall always be of value 2. If another value is used, negotiation fails. 
A.7.1.5.2 Constant parameter 2 

This parameter must always be present. The negotiation rule accepts any value for constant parameter 2 and always 
produces the constant parameter value (see A.6.4.1.3) as a result. 

A.7.1.5.3 Framing mode 

The negotiation rule selects the lower of the two values. 
A.7.1.5.4 Maximum number of outstanding LT frames, k 

The value for the maximum number of outstanding LT frames, fc, will be the lower of the two values. If the resultant 
value is an unsupported number, then negotiation fails. 

A.7.1.5.5 Maximum information field length, N401 

The maximum information field length, N401, will be the smaller of the two values. If the resultant value is an 
unsupported size, then negotiation fails. 

A.7.1.5.6 Unknown parameters 

During negotiation, the responder shall ignore all unknown parameters. When the responder sends its response LR, it 
includes only those parameters which it both received and understood. 

A.7.2 Disconnect phase procedures 

The LD frame is used to terminate a connection between two error-correcting entities. When an LD frame is received by 
an error-correcting entity, the entity shall terminate all protocol procedures and terminate the physical connection. 

A.7.2.1 User-initiated disconnect 

At the end of user data transfer, the user may initiate disconnection of the error-corrected connection. The interface 
between the user and the error-correcting entity is beyond the scope of this Recommendation. 

A user-initiated disconnect may cause the error-correcting entity to send an LD to terminate the enor-con^ted 
connection. After sending the LD or immediately if the LD is not sent, the error-correcting entity shall terminate he 
physical connection. It is recommended that the LD frame not be sent in order to promote proper interworking with the 
installed base of error-correcting DCEs. 

A.7.2.2 Establishment rejection 

During the protocol establishment phase, both negotiation initiator and responder entities may reject the attempt to 
establish an error-corrected connection. 

If the disconnect phase is initiated by a failure of the negotiation rules, the error-correcting entity shall send an LD to 
terminate the error-corrected connection. After sending the LD, the error-correcting entity shall terminate the physical 
connection. 

If the disconnect phase is initiated by the expiration of timer T401 and the receipt of protocol messages with an invalid 
frame check sequence, the error-correcting entity shall send an LD to terminate the error-corrected connection. After 
sending the LD, the error-correcting entity shall terminate the physical connection. 

If the disconnect phase is initiated by the expiration of timer T401 and no protocol messages were received, the 
error-correcting entity shall terminate operation without sending an LD. The physical connection shall continue to 
operate and data from the DTE interface will be directly presented to the signal converter for transmission over the 
physical connection in start-stop data transmission without error correction. 
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A.7.2.3 Protocol errors 



If the error-correcting entity receives unexpected protocol messages or no response from the remote error-correcting 
entity, the local entity will release the connection by sending an LD to terminate the error-corrected connection. After 
sending the LD, the error-correcting entity shall terminate the physical connection. 

A.7.2.4 Excessive retransmissions 

If the error-correcting entity repeats transmission of a frame and exceeds N400, the maximum number of attempts to 
complete a transmission, the local entity will release the connection by sending an LD to terminate the error-corrected 
connection. After sending the LD, the error-correcting entity shall terminate the physical connection. 

A.7.3 Data phase procedures 

The data phase is entered once the physical connection is established and the protocol establishment phase is completed. 
The procedures that apply to the transmission of user data frames and acknowledgements during the information phase 
are described below. 

The LT and LA frames are used to transfer user data across an error-corrected connection. 
A.7.3.1 Sending an LT frame 

When an error-correcting entity has user data to transmit, the entity will transmit an LT with an N(S) equal to its current 
send state variable V(S). Each LT shall contain no more than N401 user octets in the information field. At the end of 
transmission of the LT frame, the error-correcting entity will increment, modulo 256, its send state variable V(S) by 1 
and decrement S(k) by 1. 

If timer T401 is not running at the time of transmission of an LT frame, it will be started. When k = 1 , the timer is started 
after the error-correcting entity completes LT frame transmission. When k > 1, the timer is started when the error- 
correcting entity begins LT frame transmission. 

If S(k) - 0, the error-correcting entity will not transmit any LT frames until S(k) is updated to a non-zero value through 
the receipt of an LA frame. 

A.7.3.2 Receiving an LT frame 

When an error-correcting entity receives a valid LT frame whose send sequence number N(S) is equal to the local 
receive state variable V(R), the error-correcting entity will accept the information field of this frame and increment by 
one, modulo 256, its receive state variable V(R). 

Reception of an LT frame will start timer T402 if timer T402 is not already running. 

Reception of an LT frame may also cause transmission of an acknowledgement (LA) frame (see A.7.3.3). 

A.7.3.2.1 Reception of invalid frames 

When an error-correcting entity receives an invalid frame (see A.5), it shall discard this frame. 
A.7.3.2.2 Reception of out-of-sequence LT frames 

When an error-correcting entity receives a valid LT frame whose send sequence number N(S) is not equal to the current 
receive state variable V(R), the error-correcting entity shall discard the information field of the LT frame and transmit an 
LA frame as described in A.7.3.3. 

The first reception of an LT frame with N(S) = V(R) - 1 , however, is ignored and does not cause transmission of an 
LA frame. 

A.7 .3.2.3 Reception of LT frames without receive credit 

When an error-correcting entity receives a valid LT frame when the receive credit R(k) = 0, the error-correcting entity 
shall discard the information field of the LT frame and transmit an LA frame as described in A.7.3.3. 
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A.7.3.3 Sending of an LA frame 

An error-correcting entity sends an LA frame to acknowledge successful reception of one or more LT frames or to signal 
the correspondent entity of a condition which may require retransmission of one or more LT frames. The LA frame also 
communicates the receiver's ability to accept additional LT frames. 

The transmission of an LA frame can occur under two sets of conditions grouped according to the value of k. 
A.73.3.1 * = 1 

When k = 1 , an LA frame shall be sent if one of the following conditions occurs. The conditions are listed in declining 
order of precedence. 

a) An invalid frame is received (see A.5). 

b) An LT frame is received out-of-sequence (see A.7.3.2.2). 

c) An LT frame is received without receive credit (see A.7.3.2.3). 

d) An LT frame is properly received. 

A.7.3.3.2 k>l 

When k > 1, an LA frame shall be sent if one of the following conditions occurs. The conditions are listed in declining 
order of precedence. 

a) An invalid frame is received (see A.5). 

b) An LT frame is received out-of-sequence (see A.7.3.2.2). 

c) An LT frame is received without receive credit (see A.7.3.2.3). 

d) Timer T404 expires. 

e) One or more correctly received LT frames have not yet been acknowledged and there is no user data to 
transmit. 

f) One or more correctly received LT frames have not yet been acknowledged, there is user data to transmit, 
and the number of correctly received but unacknowledged LT frames is equal to or greater than kll. 

g) One or more correctly received LT frames have not yet been acknowledged, there is user data to transmit, 
and the number of correctly received but unacknowledged LT frames is less than fc/2, and timer 
T402 expires. 

Timer T404 shall be started when an error-correcting entity enters the data phase. Timer T404 shall be restarted 
whenever an LA frame is sent. 

A.7.3.4 Receiving an LA frame 

When an LA frame is received, the receiving error-correcting entity will consider the N(R) contained in this frame as an 
acknowledgement for all LT frames it has transmitted with an N(S) up to and including the received N(R). Timer T40 
will be stopped if no additional LT frames remain unacknowledged, i.e. the received LA frame acknowledges all 
outstanding LT frames. Timer T401 will be restarted if additional LT frames remain unacknowledged. 

An error-correcting entity that receives an LA frame uses the N(k) contained in the frame, minus the number of still 
unacknowledged LT frames in transit, as the new S(/c) value. 

A.7.3.5 Retransmission of LT frames 

An error-correcting entity will initiate retransmission of LT frames when it has sent LT frames that have been 
acknowledged and one of the following conditions occurs: 

a) An LA frame is received with an N(R) value equal to the N(R) of the last received LA frame. 

b) Timer T401 expires. 

Retransmission starts with the first LT frame in sequence which has not yet been acknowledged. 

If S(*) = 0, the error-correcting entity will not retransmit any LT frame until S(fc) is updated to a non-zero value through 
the receipt of an LA frame. 
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Timer T401 shall be restarted at the time of retransmission of the first LT frame in sequence. When k - 1, the timer is 
started after the error-correcting entity completes LT frame transmission. When k > 1, the timer is started when the 
receiving entity begins LT frame transmission. 

During retransmission, the receipt of an LA frame may acknowledge some of the LT frames pending retransmission; any 
acknowledged LT frames are not retransmitted. 

A. 7.3.6 Link failure detection 

A transmitting error-correcting entity maintains a count of the number of times a particular LT frame is retransmitted. If 
this count for any LT frame reaches N400, failure of the connection is assumed and the error-correcting entity enters the 
disconnect phase. 

A. 7.4 Break-signalling procedures 

The error-correcting entity in the data phase shall use the break-signalling procedures when it receives a break signal 
from the user at the V.24 interface. The break signal shall cause the transmission of a link attention (LN) frame. The 
procedures that apply to the transmission of the LN frame are described below. 

The link attention (LN) and link attention acknowledgement (LNA) frames are used to transfer break signals across an 
error-corrected connection. 

A.7.4.1 Sending an LN frame 

When an error-correcting entity has a break signal to transmit, the entity will transmit an LN frame with an N(SA) equal 
to its current attention send state variable V(SA). Timer T401 shall be started after the LN is sent. 

An LN frame can only be transmitted if there is no outstanding LN frame which has not yet been acknowledged. 

If an expedited LN frame is specified, the LN frame shall be transmitted immediately if no transmission is in progress, or 
immediately following the transmission in progress, if any. Non-expedited LN frames are sent after the 
acknowledgement of any LT frames pending transmission or retransmission at the time of the LN request, but before any 
subsequent user data. 

A.7.4.2 Effect of a transmitted LN frame on data 

See Table 4. 

A.7.4.3 Receiving an LN frame 

An error-correcting entity shall begin the break-signalling procedures when the entity receives a valid LN frame whose 
attention send sequence number N(SA) is equal to the attention receive state variable V(RA). The error-correcting entity 
shall accept this frame and increment its attention receive state variable V(RA) by one, modulo 256. If a valid LN frame 
is received with N(SA) less than V(RA), the error-correcting entity shall ignore the break signal of the LN frame. 

Reception of any valid LN frame shall cause transmission of a link attention acknowledgement (LNA) frame by the 
error-correcting, as described in A.7.4.5. 

A. 7.4.4 Effect of a received LN frame on data 

See Table 5. 

A.7.4.5 Sending an LNA frame 

An error-correcting entity uses an LNA frame to acknowledge successful reception of an LN frame. It is transmitted in 
response to receipt of a valid LN frame. The LNA frame shall contain an N(RA) value equal to the N(SA) value 
contained in the received LN frame. 

A.7.4.6 Receiving an LNA frame 

A received LNA frame that contains N(RA) shall be the acknowledgement for the LN frame transmitted with an N(SA) 
equal to the received N(RA). If the received N(RA) is equal to N(SA) for the outstanding LN frame, timer T401 will be 
stopped and the attention send state variable V(SA) be incremented by 1, modulo 256. 
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After proper receipt of the LNA frame to acknowledge the outstanding LN frame, the break-signalling procedure is 
completed and the error-correcting entity resumes the sending of user data. 

A.7.4.7 Retransmission of LN frames 

At the expiration of timer T401, the error-correcting entity will retransmit the unacknowledged LN frame. The 
unacknowledged LN frame will also be retransmitted if an LNA frame is received with an N(RA) value less than N(SA). 

Timer T401 shall be restarted at the time of transmission of the LN frame. 
A.7.4.8 Link failure protection 

A transmitting error-correcting entity shall maintain a count of the number of times a particular LN frame is 
retransmitted. If this count for any LN frame reaches N400, failure of the connection is assumed and the error-correcting 
entity enters the disconnect phase. 

A.7.5 List of error-correction system parameters 

A.7.5.1 Timer T401 - Acknowledgement timer 

The period of timer T401, at the end of which retransmission of a frame may be initiated, shall take into account whether 
T401 is started at the beginning or the end of the transmission of a frame. 

The period of timer T401 in the protocol establishment phase shall be in the range 0.5-9 seconds. 

The period of timer T401 for transmission of LT and LN frames is dependent on the transmission speed of the physical 
connection and shall be determined by the following formula: 



2{(*/2) x LbiLf + L lt + N401) + L b (L f + L la )) 



T401 > 



bit/s 



where: 

L b is the number of bits (framing mode 2=10, framing mode 3 = 8) 

Lf is the length of frame overhead (octet-oriented framing mode = 7, bit-oriented framing mode = 4) 

L tt is tne length of LT header field (non-optimized data phase = 5, optimized data phase = 3) 

L ia »s the length of LA header field (non -optimized data phase = 8, optimized data phase = 4) 

T rt is the round trip propagation delay (including remote processing and queuing delay) 

bit/s is the physical connection speed in bits per second 

Typical values are shown in Table A.9 



TABLE A.9/V.42 
Timer T401 values for transmission of LT and LN frames 



Physical connection 
speed (in bit/s) 


Period (in seconds) for 
N401 = 64 


Period (in seconds) for 
N401 = 256 


1200 


6 


16 


2400 


4 


9 
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A.7.5.2 Timer T402 - LA timer 



The period of timer T402, at the end of which an acknowledgement must be sent, shall indicate the maximum amount of 
time available to the error-correcting entity between transmission of the acknowledging frames in order to ensure receipt 
of acknowledgements by the correspondent entity, prior to timer T401 expiring at the correspondent entity (timer T402 = 
0.5 timer T401). 

A.7.5.3 Timer T403 - Inactivity timer 

The error-correcting entity may, optionally, support a timer T403 with a period of at least 59 seconds. The period of 
timer T403 shall be used by an error-correcting entity to detect a half-open connection condition in which the 
correspondent entity is non-active and non-operational. 

T403 is started upon entering the data phase and is restarted upon receipt of any valid frame. 

If T403 is enabled and expires, the observing entity shall enter the disconnect phase and terminate the connection. 

A.7.5.4 Timer T404 - Flow control timer 

The period of timer T404, at the end of which transmission of an acknowledgement frame is sent, shall be used during 
the data phase of an error-corrected connection. The period of timer T404 shall be dependent on the transmission rate of 
the physical connection and shall be determined by the Table A. 10. 



TABLE A.10/V.42 
Timer T404 values 



Physical connection speed 


Period 


(in bit/s) 


(in seconds) 


1200 


7 


2400 or faster 


3 



A.7.5.5 Maximum number of retransmissions (N400) 

The value of N400 shall indicate the maximum number of attempts made by the error-correcting entity to complete the 
successful transmission of a frame to the correspondent entity. 

The value of N400 shall be 12. 

A.7.S.6 Maximum number of octets in an information field (N401) 

The value of N401 shall indicate the maximum number of octets in the information field, excluding DLE octets (in start- 
stop, octet-oriented framing mode) or 0 bits (in bit-oriented framing mode) inserted for transparency, that an error- 
correcting entity is willing to accept from the correspondent entity. 

The value of N401 shall be determined during the protocol establishment phase by LR variable parameter 4 
(see A.6.4.1.7). 

NOTE - Applications should support a value of N401 = 64. 
A.7.5.7 Maximum number of outstanding LT frames (k) 

The value of k shall indicate the maximum number of sequentially numbered LT frames that the error-correcting entity 
may have outstanding (i.e. unacknowledged). 
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The value of k shall be determined during the protocol establishment phase by LR variable parameter 3 (see A.6.4.1.6). 

The value of k shall never exceed 255. 

NOTE - Applications should support a value of A: = 8. 

Annex B 

Mapping of character formats to 8-bit format 

This Annex presents the mapping for converting between character formats used on the DTE/DCE interface and those 
used on the control function/error control function interface. Only support of the 10-bit DTE-to-DCE format is 
mandatory; support of the other formats shown here is optional. Character formats other than those listed below are not 
supported. 



DTE/DCE: 
Total bits per 
character 


Specific formats 
of octets supported 


Control function to error control function ! 
formatting of octets 


11 


Start/8 data/2 stop 
Start/8 data/parity/stop 


8 data (parity or second stop bit is independently generated on each 
DTE/DCE interface) 


10 


Start/8 data/stop 


8 data 


Start/7 data/2 stop 


7 data plus 0-bit pad in high-order bit 


Start/7 data/parity/stop 


7 data plus parity as high-order bit 


9 


Start/7 data/stop 


7 data plus 0-bit pad in high-order bit 


Start/6 data/2 stop 


6 data plus two 0-bit pads in two highest-order bits 


Start/6 data/parity/stop 


6 data plus parity in next- to-high-order bit plus 0-bit pad in high-order 
bit 


8 


Start/6 data/stop 


6 data plus 0-bit pad in two highest-order bits 


Start/5 data/2 stop 


5 data plus three 0-bit pads in three highest-order bits 


Start/5 data/parity/stop 


5 data plus parity in third highest-order bit plus two 0-bit pads in two 
highest-order bits 
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Appendix I 
Interworking with a non-error correcting DCE 



This Appendix presents some considerations for interworking between an error-correcting DCE and a non-error- 
correcting DCE. 



1.1 Interworking with a non-error-correcting answerer 

A non-error-correcting answering DCE will pass the ODP through to its attached DTE. When passed through the 
asynchronous-to-synchronous converter of a DCE, the ODP produces a bit sequence that is interpreted by a large 
majority of DTEs as a series of IA5 characters of alternating parity (assuming that the DTE is using the following data 
format: one start bit, seven data bits, parity, one stop bit). The sequence may interfere with automatic baud rate or 
character format detection mechanisms of the answerer or cause the inadvertent bypassing of prompts necessary to the 
establishment of non-error-corrected DTE-to-DTE communications. In this event, it will be necessary for the originator 
to disconnect, manually disable error correction, and reattempt the call. 



1.2 Interworking with a non-error-correcting originator 

An error-correcting answerer called by a non-error-correcting originator will send only mark bits, which cause no 
observable effect at the originating DTE (since mark-idle is the "normal" state for an asynchronous DTE). After the 
detection phase timeout period, the error-correcting answerer will revert to non-error-correcting-DCE operation 
(i.e. non-error-correcting mode). 



1.3 Disposition of unrecognized bits 

If the detection phase is successful (i.e. the error-control DCEs each recognize the error-control capabilities of the other 
and move into the protocol establishment phase), none of the bits received during the detection phase (i.e. the ODP and 
the ADP) are delivered to the DTE. 

If the detection phase fails, an error-correcting DCE reverts to the non-error-correcting-DCE operation. While the bits 
received during the failed detection phase were of no value to the error control function, they may indeed have been of 
value to the DTEs, since the non-error-control DCE will have already given its attached DTE the go-ahead to begin 
transmitting. There are several possible options for handling these bits, as discussed below; other possibilities also exist. 

a) The error-correcting DCE may discard the bits received during the detection phase timeout period. This 
disposition is the minimal implementation. If the DTE attached to the non-error-correcting DCE did 
transmit data during the timeout period, it would be necessary, in this case, for the transmission to be 
repeated if, indeed, the fact that the bits were discarded is recognizable (perhaps because the transmission 
was meant to evoke some type of response, which fails to materialize). 

b) The error-correcting DCE could buffer bits received during the detection phase and, upon termination of 
the detection phase, forward all of these bits to the DTE. Because of the possibility of continuous 
transmission from the other DTE, this optional mode of operation would likely require the 
implementation of fully-buffered operation (i.e. every character received is held for forwarding after 
previously-received characters have been forwarded). While the non-error-correcting-DCE Recommen- 
dations do not require this mode of operation, the error-correcting DCE Recommendation does require 
fully-buffered operation anyway (as well as DTE/DCE flow control) because of the possibility of 
retransmission in the event of errors. Buffered and flow-controlled operation without error control could 
thus be considered a recognized subset of the error-correcting Recommendation that manufacturers could 
choose to implement and make available to users. This not only overcomes possible lost data during the 
detection phase, but also supports a constant-speed DTE/DCE interface during non-error-correcting 
operation. This Recommendation does not require this mode of operation to be available, however. 
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Appendix II 
Data forwarding conditions 



The control function is responsible for determining when to initiate data transfer for the purpose of transmitting the data 
received on the V.24 interface to the remote DCE. While it is beyond the scope of this Recommendation to specify when 
the control function initiates data transfer, several data-forwarding criteria are possible. These include the following: 

a) Data forwarding character (this corresponds to parameter 3 of Recommendation X.3) - The control 
function may trigger transmission of data received based on reception across the V.24 interface of a 
pre-designated character or character sequence. 

b) Idle timer (this corresponds to parameter 4 of Recommendation X.3) - With this method, the control 
function starts a timer whenever a new character is received across the V.24 interface. If a predetermined 
period passes without receipt of a further character, the control function instructs its error control function 
to transmit the accumulated characters. 

c) Interval timer - With this method, the control function accumulates characters from the V.24 interface for 
a period of time. When this time has elapsed, the control function instructs its error control function to 
transmit the accumulated characters. 

d) Stream mode - Upon receipt of a character from the V.24 interface, the control function instructs its error 
control function to commence transmission of data. As the error control function is transmitting an 
1 frame to carry this data and prior to appending the FCS field to close out the 1 frame, the control 
function may provide to the error control function additional characters received from the V.24 interface 
for inclusion in the I frame. 

e) Block mode - The control function may accumulate a predetermined number of characters before 
requesting their transmission by the error control function. 

Other data-forwarding criteria may also be used by the control function. The control function may use several methods 
at the same time. 



Appendix III 

Additional information for V.42 implemented 
regarding robustness of operation 

Certain procedures, techniques, parameter values, and behaviours may be included in implementations of the detection 
phase and the LAPM protocol, which may improve the performance of the detection phase and LAPM under some 
channel conditions (e.g. high bit error rates). Implementation of these procedures, etc., is not required for compliance 
with this Recommendation, but is permitted by this Recommendation. If the procedures are implemented, there will be 
no adverse impact on interoperability with DCEs which do not implement the procedures. 

This informative Appendix indicates the places in the text of this Recommendation where these procedures are 
referenced, described or permitted, and the potential benefits that may be gained by their implementation. The 
information contained in this Appendix is not exhaustive, and is not intended to preclude other improvements which may 
be possible. 

III.l Transmission of the answerer detection pattern 

Subclause 7.2.1.3 requires the answerer to transmit the answerer detection pattern "at least ten times". Since the 
originator detection pattern has been received, the answerer possesses a high degree of confidence that the originator is 
indeed capable of LAPM operation; in this case, it would be advisable to transmit the ADP much more than ten times, 
possibly until flags are received from the originator. This will increase the opportunity for recovery from the event that 
no two consecutive patterns of the first ten ADPs are received correctly, thereby increasing the probability of successful 
connection establishment. 
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IIL2 Value of parameter N400 (maximum number of retransmissions) 

Subclause 9.2.2 specifies that N400 shall have a minimum value of 1, but specifies no maximum or recommended value. 
For increase robustness under adverse channel conditions, this parameter should be set to a relatively large value 
(e.g. 16), such that repeated attempts of a procedure requiring a response shall be made over a span of several seconds 
(depending upon the data signalling rate). 

In particular, it should be noted that after successful completion of the detection phase (see 7.2.1) that the originator 
possesses a high degree of confidence that the answerer is indeed capable of LAPM operation. In this case, it would be 
advisable to use a high value of N400 during the protocol establishment phase in order to increase the probability of 
successful connection establishment. However, if the detection phase is omitted, the value of N400 may need to be small 
to accommodate fallback operation with non-error-correcting DCEs and with DCEs which support only the alternative 
protocol. 



IIL3 Incomplete XID exchange 

Subclause 8.10.3 specifies that after an XID command frame is sent N400 times without a valid response that "... the 
error-correcting entity shall notify the control function that the negotiation/indication procedure did not complete." 
It should be noted that the recipient of the XID command frame may have indeed processed it and transmitted on 
XID response frame, perhaps multiple times, with the responses being corrupted and discarded; in this event, if the 
sender of the XID command frame were to continue the connection, the parameters of the two error-correcting entities 
(and possibly higher-level functions such as V.42 bis data compression) may be different, resulting in an ultimate failure 
of the connection, loss or corruption of user data, or both. It is therefore advisable that, in the event the XID exchange 
fails, the call be released. 



III.4 Selective retransmission 



The selective reject (SREJ) command/response is described in 8.2.4.8, 8.4.5, and 8.5.1. When SREJ is implemented in 
both error-correcting entities and enabled by negotiation (see clauses 10 and 12), it may be used to improve the 
performance of the LAPM connection under adverse conditions (and when propagation delay is long, such as on satellite 
circuits). This gain is achieved because, when one or more frames are lost due to line noise, the SREJ procedure requires 
retransmission of only the lost frame(s), while the normal REJ procedure requires retransmission of the first lost frame 
and all subsequent frames; SREJ thus improves performance by eliminating the repeated transmission of data which has 
already been successfully received. 



III.S Reject on detection of errored frames 

Subclause 8.5.4 permits the recipient of an errored frame, under certain conditions, to immediately issue a REJ frame 
rather than simply discarding and ignoring the frame. Implementation of this optional provision can decrease the time 
required to recover from a line error. It may be advisable to issue such an "early REJ" frame only when the errored 
frame consists of five bytes or more; this will avoid issuing REJ frames when the error was caused by a corrupted flag or 
supervisory frame. 



III.6 Checkpointing 

Recovery from loss of the last I frame in a series may be expedited if that I frame is followed by a supervisory command 
frame (such as RR) with the Poll bit set to 1 . The short supervisory frame is more likely to be received without error than 
is the preceding longer 1 frame, and, with the poll bit set, requires the receiver to respond immediately with an indication 
of whether or not the preceding I frame was properly received. This technique, known as checkpointing, reduces the 
dependency on timer recovery of lost I frames and can improve performance under adverse conditions. 

Caution should be exercised in frequent invocation of this mechanism so as to avoid degradation of throughput in the 
reverse direction due to the need for the remote error-correcting entity to insert a supervisory response frame with the 
final bit set into the reverse data stream upon each such invocation. 
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Appendix IV 



Factors for determining the acknowledgement timer 



Several procedures of the error control function utilize an acknowledgement timer (T401) to ensure timely receipt of the 
acknowledgement from the remote error control function. To ensure receipt of such an acknowledgement before the 
transmitter's T401 expires, the two communicating error control functions must take into account the following time 
factors: 

a) the propagation delay involved in transmitting the frame requiring acknowledgement - (T a ); 

b) the time needed for the remote DCE to process the received frame and formulate the acknowledgement - 

c) the maximum time allowed to complete transmission of those frames in the remote DCE's "transmit 
queue" (e.g. a frame already in progress of being transmitted or a frame that cannot be displaced) - (T c ); 

d) the time needed to transmit the acknowledging frame - (7j); 

e) the propagation delay involved in transmitting the acknowledging frame - {T e )\ 

f) the processing time needed by the error control function to recognize the acknowledging frame - (7y). 

Given values for the above time limits, the value of the acknowledgement timer used by the transmitting error control 
function should then be set as follows: 

T401 > T a + T b + T c + T d + T e + T f 



Appendix V 
Potential enhancements to LAPM protocol 



During the development of this Recommendation, several issues were raised that may lead to enhancements to the 
LAPM protocol (defined in the main body of this Recommendation) or modifications to related V-Series 
Recommendations during the 1989-1992 Study Period. This Appendix briefly reviews these issues so that manufacturers 
are aware of the likely development path of this Recommendation. Unless otherwise specified, the enhancements would 
be implemented as optional features. 

V.l Data compression 

The performance of the error-correcting DCE may be enhanced considerably through the use of data compression on the 
character stream received from the DTE prior to transmission by the error control function. 

V.2 Forward error correction 

In certain applications of V-Series Recommendations modems, the bit error rate occurring over the physical connection 
may be sufficiently high to seriously reduce the throughput obtained by the error control function. An example of this 
type of application is the use of modems for data transmission over cellular radio links. Under these conditions, 
performance may be improved if the output of the error control function is encoded using a forward error-correction 
code prior to transmission over the physical connection. 
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V.3 Statistical multiplexing 



Multiplexing of several streams of user data over a single physical connection may be performed in two ways. The 
procedures described in the LAPM definition are able to support multiple logical connections; therefore, a separate 
DLCI could be associated with each data stream. Alternatively, a single logical connection may be used to transport data 
from several DTEs that would require some means of structuring the information field of an I frame. 



V.4 End-to-end transport of interface state information 

A common requirement related to subclause V.3 is the ability to replicate the state of a subset of the V.24 interface leads 
at the remote DTE/DCE interface as, for example, described in Recommendation V.l 10. This could be accomplished by 
using a Ul frame (see 8.6 and 123) and encoding the interface circuit states within the information field, or by adding a 
header to each I frame. 



V.5 Issues related to control function-to-control function information exchange 

a) A DLCI value has been reserved for the transport of control function-to-control function information 
between the peer-DCE control functions. The protocol for this information exchange has been left for 
further study. 

b) Loop-back testing between control functions is possible using the procedures defined within LAPM. 



V.6 Rate negotiation 

The DCE control functions may communicate information relating to the available transmission speeds and modulation 
schemes over the DLCI discussed in subclause V.5 so that a fallback/fall-forward strategy may be agreed. This has 
particular application in multi-standard DCEs where the ability to switch between, for example, Recommendations V.32 
and V.22 during the call may result in performance improvements due to poor line quality. 

V.7 Operation over an asymmetric or half-duplex physical connection 

Several issues were raised relating to operation over an asymmetric or half-duplex connection. The performance of the 
error-correcting protocol may be optimized for use over a specific physical connection; however, the means by which 
this is accomplished are for further study. One possible technique is described in subclause V.8 below. Another possible 
technique is given in Recommendation X.32 and is known as LAPX for operation on half-duplex connections. 



V.8 Multiple frame reject 

The selective reject mechanism defined for LAPM permits several I frames to be individually rejected; however, a 
control frame - SREJ - must be transmitted for each frame rejected (i.e. for each frame for which retransmission is 
requested). In certain applications, for example, for use with a half-duplex physical connection, performance would be 
significantly improved if a single control frame could be used to request retransmission of several I frames, not 
necessarily consecutive. The control frame (MREJ) could contain an information field with a bit map of length k bits, in 
which the state of each bit indicates the acknowledgement or rejection of the corresponding frame within the £-frame 
window of outstanding frames. 



V.9 Character format indication/negotiation 

While it is possible for the start-stop mode character format associated with each DTE/DCE interface (i.e. the format 
used by the DTE at each end of the connection) to be different, certain inconsistencies would not be permitted. In the 
case of differences in the use of parity or the number of stop bits, it is sufficient that the data bits are carried end-to-end. 
If the character formats at the two DTE/DCE interfaces differ in the number of data bits, the call must be cleared or the 
DCEs negotiate a common format. This is for further study. 
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V.10 Preservation of framing/parity errors 



When an 11-bit character format is used, there is no mechanism defined ^ ^^^S^J^Z^ 
indicated to the remote DTE. In addition, other character-format errors detected at the DTE/DCE interface would not be 
Inalled. Tnere are two alternative options; to remove the requirement for octet alignment and, hence, allow a mnth or 
subsequent bits to be sent, or to send subsidiary information when an error is detected. 

V.ll Encryption 

The use of encryption within an error-correcting DCE has some advantages, specifically when used in conjunction with 

data is received from the DTE, the properties that would «^^^^ 
compression may be affected by the encryption process and, hence, poor compression achieved. ^ effectiveness ot 
r^Sn empSyS after the data is compressed is higher, due to the lower redundancy within the encoded stream. 

V.12 ISDN compatibility 

Some advantage may be obtained from compatibility with ISDN access protocols in applications involving 1SDN/GSTN 
fnTrt^king fe w^erS dial-up access to ISDN services or subscribers is required. LAPD-based protocols have been 
proposed for several applications within ISDN, for example, terminal adaption. 
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